存储与容量管理
服务器单机部署应分别管理租户数据、容器镜像和部署备份。软件版本升级不会扩大云盘、LUKS 卷或文件系统。扩容期间不要同时启动软件升级。
存储规划
| 位置 | 用途 | 管理要求 |
|---|---|---|
| 系统盘及部署目录 | 系统软件、部署配置、升级状态和加密数据库备份 | 系统盘建议至少 60 GiB；升级前预留备份和临时空间 |
| Docker 存储 | 新旧容器镜像、容器可写层和日志 | 按 Docker 实际配置的存储路径检查容量 |
/srv/soln/data | PostgreSQL 与 MinIO 的持久数据，包含工作流数据库和附件 | 正式企业部署优先独立加密数据盘，按业务增长规划容量 |
保持 SOLN_DATA_ROOT 的挂载路径不变，可以在扩容或迁移后继续使用现有租户和部署目录。8 GiB 加密文件卷只是小容量示例，不是企业数据盘的默认容量。扩大系统盘不会自动扩大其中的 LUKS 文件卷。
查看容量
在部署服务器的 root 终端执行：
sl storage status --dir /opt/soln-tenant-runtime --json
命令显示部署文件系统、租户数据文件系统、挂载来源、可用容量，以及 Docker 存储信息。诊断问题列在 errors 中；容量无法读取时不能当作检查通过。数据卷在 Linux 上必须是实际挂载点，目录存在和权限为 700 不足以证明已经挂载。
dataMount.encryption=luks 表示识别到了 Linux 加密映射；unverified 表示没有核实加密方式，不能据此推断磁盘未加密或已加密。云平台原生加密需要管理员在云控制台核实，配置中的加密声明不能替代实际加密。
已安装部署使用当前 Runtime 镜像运行短暂的只读容量探测容器，从 Docker 所在主机读取存储容量，避免把升级辅助容器的磁盘当作宿主机磁盘。探测完成后自动移除容器，不读取租户文件内容。
Docker containerd 镜像存储
启用 containerd image store 的 Docker，镜像可能位于 DockerRootDir 之外。先检查：
docker info --format '{{.DockerRootDir}}'
docker info --format '{{json .DriverStatus}}'
出现 io.containerd.snapshotter.v1 时，管理员需核对 containerd 的实际存储目录，在部署 .env 中设置 SOLN_DOCKER_IMAGE_STORE_PATH。默认安装常见目录是 /var/lib/containerd，有自定义配置时必须使用实际路径，不能直接套用。
SOLN_DOCKER_IMAGE_STORE_PATH=/替换为实际镜像存储目录
首次安装尚无 .env 时写入 .env.example。该字段用于容量检查，不会迁移镜像或修改 Docker 配置。升级发现启用了 containerd 镜像存储但未配置路径时会停止，避免用另一块磁盘的容量作判断。
升级前的空间检查
sl upgrade --dir /opt/soln-tenant-runtime --check --json
存在可用更新时，CLI 分别检查：
- 镜像存储：尚未下载的新版产品镜像压缩层大小的四倍，作为下载、解压和存储余量。
- 部署目录：当前租户数据库大小的两倍，作为加密数据库备份余量。
- 租户数据卷：当前租户数据库大小的两倍，作为迁移写入余量。
- 每个文件系统：额外保留 1 GiB；多个位置在同一文件系统时合并预算。
这是保守的空间预算，不是每次数据库迁移的精确大小，也不包含未来业务增长。没有可用更新时不会计算新版预算。doctor 还要求单机租户数据文件系统至少有 1 GiB 可用空间。
空间不足时 CLI 在停止业务和执行数据库迁移前中止。租户内的软件升级使用同一套检查，错误中显示不足的存储类型及需要的容量。升级备份保存在 <部署目录>/.soln/backups，不自动迁移到租户数据盘；数据库备份不包含 MinIO 附件。
升级产物自动清理
软件升级成功后，CLI 确认 Runtime、Web、Worker 使用本次版本的镜像并就绪，再清理过期产物。租户页面发起的软件升级采用相同规则。保留当前版本、上一版本的镜像和签名文件，以及回滚所需的加密数据库备份。
清理更早的 CLI 升级备份、版本 Compose 文件、签名目录和已记录的产品镜像引用；版本之间共用的镜像继续保留。仅本部署中已成功退出的 Migrator 和贴纸初始化容器可随过期镜像清理，其他容器使用的镜像不会强制删除。
查看清理预览，不删除任何产物：
sl storage cleanup --dir /opt/soln-tenant-runtime --json
确认当前版本正常后执行清理：
sl storage cleanup --dir /opt/soln-tenant-runtime --yes --json
清理不会全局裁剪 Docker 镜像，不删除数据卷、租户业务数据、密钥或手动备份。产品镜像记录在 .soln/cleanup-inventory.json 中，未记录的历史镜像不会自动删除。升级备份只服务于上一版本回滚，不能替代独立的业务备份。
无法确认新版就绪时暂缓清理。清理警告记录在升级结果的 cleanup 中，不会把已经成功的软件升级判为失败；处理警告后可重新执行清理。升级、回滚、清理共用 .soln/lifecycle.lock 操作锁；进程中断后若遗留锁目录，必须先确认没有相关操作正在运行，再手工移除。
按时间清理日志
空间管理员可通过 Runtime 命令注册表清理租户日志。请先使用 sl login 登录租户的空间管理员账号；部署登录属于另一种会话。日志清理与升级产物清理分别执行，软件升级时不会自动清理业务日志。
sl system log category list --json
# 预览截止时间之前的日志，不包含截止时间本身
sl system log cleanup --category all \
--before '2026-07-01T00:00:00+08:00' --limit 500 --json
# 执行同一批次
sl system log cleanup --category all \
--before '2026-07-01T00:00:00+08:00' --limit 500 --yes --json
将 all 替换为单个分类标识，可只清理该分类。--before 必须为带时区且早于当前时间的 ISO 时间。--limit 限制每个分类单批处理的主记录数，范围 1–1000，默认 500。hasMore 为 true 时，使用相同截止时间继续执行。selected 表示本批选中的主记录数，affected 表示删除或清理详情的主记录数，detailRows 表示清理的子记录详情数。预览不会锁定记录，执行结果可能变化。
| 日志分类 | 分类标识 | 清理规则 |
|---|---|---|
| 登录记录 | auth | 删除过期登录审计记录，保留有效会话 |
| 系统操作审计 | audit | 删除过期操作审计记录及其搜索副本 |
| 自动化执行 | automation | 清理已结束执行的错误详情和节点输入诊断，保留摘要、输出结果与人工任务凭证 |
| 脚本执行 | script | 删除已结束的 Studio 执行日志，保留脚本、绑定和版本 |
| OpenLink 执行 | open-link | 清理已结束执行的诊断与成功请求输入，保留失败项重试输入、结果和请求标识 |
| 模型调用 | model-usage | 清理原始用量载荷、诊断元数据和错误文本，保留 Token、费用、定价依据与配额凭证 |
| 数据处理与按钮任务 | job | 清理已结束任务的错误文本，保留结果、批次明细与通知状态 |
| 后台日志搜索 | search | 删除已结束搜索任务记录，保留源日志和导出文件 |
| 审批凭证与人工任务 | approval、workflow | 受保护：保留实例、决定、意见、讨论和人工任务 |
| AI 会话 | luna | 受保护：保留执行、事件、步骤和工具结果 |
| 执行回执 | connector、print-design、runtime-operation | 受保护：保留防止重复执行的请求标识和回执 |
| 消息与配额 | message、model-control | 受保护：保留收件箱、投递回执、配额事件、计数器与预留记录 |
运行中、等待中或已安排重试的任务不会清理。每批在当前租户范围内原子执行，并与其他日志清理互斥；成功清理后生成一条清理审计记录。清理后历史日志中的诊断细节将不再可用。PostgreSQL 通常将释放空间留作内部复用，数据文件不会立即缩小；命令不会执行 VACUUM FULL，也不会删除附件。
服务器日志
| 日志类型 | 管理方式 |
|---|---|
| systemd journal 及输出到 journal 的服务日志 | 使用下面的命令预览并清理归档文件 |
| 宿主机 Nginx 访问与错误日志文件 | 使用服务器的 Nginx logrotate 策略轮转、压缩并保留归档 |
| Docker 容器输出 | 配置日志驱动和轮转上限；Docker 文件日志不支持按时间删除单条记录 |
| PostgreSQL WAL 与数据库文件 | 由 PostgreSQL 管理，不作为普通日志删除 |
在 Linux 服务器上预览 journal 清理。以 root 身份添加 --yes 后，通过 systemd 执行轮转和归档清理：
sl storage log-cleanup --category journal \
--before '2026-07-01T00:00:00+08:00' --json
sl storage log-cleanup --category journal \
--before '2026-07-01T00:00:00+08:00' --yes --json
截止时间会换算为保留时长。systemd 按整个归档文件清理，仍包含较新记录的文件继续保留。预览显示 journal 总占用，不代表本次可释放的精确字节数。不要截断正在使用的 Nginx 或 Docker 日志文件来模拟按时间清理。
扩容与迁移
按使用比例和增长速度设置告警，可采用 70% 提醒、80% 安排扩容，同时关注绝对剩余容量。告警应覆盖租户数据盘、部署备份和镜像存储；CLI 诊断不代替持续监控。
| 存储类型 | 操作顺序 |
|---|---|
| 云平台原生加密数据盘 | 云控制台扩容，系统识别新容量，按实际布局扩大分区及文件系统 |
| LUKS 加密块设备 | 扩大底层磁盘，按实际布局扩大分区、加密映射及文件系统 |
| LUKS 文件卷 | 确认所在盘有空间，扩大容器文件，更新 loop 设备容量、加密映射及文件系统 |
| 迁移到新数据盘 | 先备份，停止业务及数据库、对象存储写入，复制并核对数据，将新盘挂载到原数据路径，再启动并验证 |
设备路径、分区、LVM 和文件系统不同，扩容命令也不同。管理员应先检查实际布局，再使用发行版及云厂商对应步骤。已有数据卷扩容不能执行 luksFormat、mkfs，也不能删除数据库目录或 Docker 数据卷来腾出空间。
迁移前保存数据库、对象数据、部署配置及必要的恢复密钥，备份放在独立故障域并验证能够恢复。不能把正在写入的 PostgreSQL 数据目录直接复制当作有效迁移。迁移后检查数据权限、数据库、附件和公网健康接口；通过验证前保留原卷。
重启恢复与密钥管理
正式交付前确定一种恢复方案：
| 方案 | 启动时的处理 |
|---|---|
| 云平台原生加密数据盘 | 云平台处理底层加密，操作系统按文件系统 UUID 自动挂载；需要核实账号、KMS 权限及盘型支持 |
| LUKS 与外部密钥服务 | 主机以受控身份取得解锁密钥，再挂载；密钥服务不可用时数据服务应停止 |
| LUKS 与人工口令 | 管理员重启后先解锁、挂载，再启动 Docker |
本机密钥文件可以用于自动解锁，但密钥与数据在同一服务器时，完整系统盘或快照的持有者可能取得密钥。使用该方案前需明确保护范围，不能将其视为独立密钥隔离。
在单机专用主机上，给 Docker 设置 RequiresMountsFor=/srv/soln/data，并保留 AssertPathIsMountPoint=/srv/soln/data，确保挂载失败时不启动租户。挂载依赖不会自动提供 LUKS 密钥；crypttab、fstab 或密钥服务必须事先完成配置。共用 Docker 的主机需要管理员设计对应服务依赖，不能直接加全局限制。
CLI 不创建或格式化数据盘，不配置自动解锁、不保存解锁密钥。重启恢复操作见服务器单机模式安装。