备份与恢复

有用的 ThreadCells 备份会保留持久化协调状态，以及解释该状态所需的配置。已安装代码和构建缓存通常可重建；数据库、操作员所有的配置和提供商原生证据则未必如此。

重要内容

按适用情况备份：

• ThreadCells SQLite 数据库及其关联的 SQLite 文件；
• 配置和服务环境，但不应将明文密钥放入临时创建的归档中；
• 操作员验证器文件，将其作为单独受保护的敏感工件；
• 若已配置，Telegram bot token 文件，将其作为单独加密的凭据，并保留所有权和模式；
• 保留策略要求的代理上下文、附件和日志；
• 解释活动工作所需的受管 worktree 和发布版本元数据；
• 精确的活动和回滚候选清单/身份；
• 外部提供商状态，但仅依照该提供商自身支持的备份策略。

Git 仓库本应已有自己的备份/远程策略。ThreadCells 数据库备份不能替代对提交的保留。

可重建内容

下载的 Web 依赖、浏览器修订版本、包缓存、临时构建目录和已验证候选内容通常可从源代码和 lockfile 重建。不要仅因缓存位于运行时路径下，就将其全部纳入每个备份。

一致的备份顺序

1. 记录活动源/候选版本身份和当前服务状态。
2. 在快照窗口期间避免启动新会话或变更操作。
3. 使用规范数据库备份机制，而不是盲目复制活动 SQLite 文件。
4. 对备份运行 SQLite 完整性验证。
5. 在保留权限且不打印内容的情况下，复制必要的配置、验证器和已配置 Telegram token 工件。
6. 记录校验和，并将归档存储在实时状态根目录之外。
7. 测试预定恢复主体能否列出和读取备份。

如果部署工具提供备份命令，请使用它：它了解实际数据库路径和服务协调。绝不要为了构建归档而将明文提供商或操作员密钥放入 shell 历史记录。

验证

至少验证复制的 SQLite 数据库：

sqlite3 /path/to/backup.db 'PRAGMA integrity_check;'

预期结果：ok。同时记录校验和，并确认归档包含预期的配置、验证器和构建身份，而不在日志中暴露其内容。

未经测试的备份只是一项假设。应定期在隔离路径和仅本地端口中演练恢复。

恢复顺序

1. 停止或隔离目标 ThreadCells 服务。
2. 保留当前失败状态以用于取证回滚。
3. 安装或选择精确兼容的候选版本。
4. 使用运行时账户预期的所有权恢复数据库和可变状态。
5. 恢复服务配置。
6. 使用不同的受信任所有者、服务可读模式和可信的父目录链恢复操作员验证器；将适用的 Telegram token 恢复到 $CAO_HOME_DIR/secrets/telegram-bot-token，作为运行时所有的常规文件，模式为 0600。
7. 启动前运行完整性检查。
8. 在回环地址启动，并验证健康状态/构建身份。
9. 重试工作前检查活动工作流、结果、终端、项目、提供商预检和 Statistics。

不要只恢复数据库而保留不匹配的代码或过时的服务环境。不要假定 tmux/提供商进程以一致状态幸存；请将每个存活进程与持久化会话状态协调。

恢复验证

恢复后，验证：

• Settings → About 与预期候选版本匹配；
• /health 成功；
• 项目和会话历史存在；
• 已投递结果仍可归属；
• 提供商可用性反映恢复后运行时用户实际安装的情况；
• 操作员授权报告已配置，且能使用现有密钥解锁；
• Telegram 报告其预期安全配置状态，并且在恢复后、启用前通过显式连接和测试消息检查；
• Statistics 总数重放时不会重复；
• 活动/回滚发布版本仍被正确识别。

备份受到自动 Housekeeping 保护。对备份存储应用单独、经审查的保留策略。

Full Cleanup 不能替代备份保留策略。它会保护规范数据库以及任何无法证明可安全处置的备份，但会有意移除可信发布元数据所表示的每个不活跃本地发布版本和回滚。授权前，请确认任何必需的恢复点都存在于本地发布集合之外并已通过完整性检查。执行后，操作员应预期本地回滚不可用，直到另一个已验证发布版本完成暂存。