Chatto备份与恢复完全指南：age加密、密钥分离与灾难恢复清单
【免费下载链接】chattoA fully-featured team and group chat application that you can easily selfhost.项目地址: https://gitcode.com/gh_mirrors/chatt/chatto
Chatto 是一款功能完整、可以自托管的团队与群组聊天应用。这篇指南带你从零掌握Chatto 备份与恢复：用一条命令打包全部数据、用 age 加密保护归档、正确分离加密密钥，并给出一份可直接抄作业的灾难恢复清单，确保磁盘故障时团队聊天记录一条都不丢。
Chatto 备份包含哪些数据
Chatto 把所有核心状态存在 NATS JetStream 里，chatto backup会把这些持久化数据打包成一个.tar.gz归档，包括：
- 服务器数据—— 用户、角色权限、房间、消息、线程、表情回应、消息正文
- 通话事实—— 房间通话的开始/加入/结束事件，用于恢复进行中通话
- NATS 侧资源—— 头像、服务器图标与横幅、消息附件
- 投影快照—— 启用
core.projection_snapshots时的加密派生状态
同时，以下数据会被有意排除：
| 数据 | 排除原因 |
|---|---|
| 加密密钥 | 默认排除（除非--include-keys），防止数据归档被偷后自解密 |
| 用户在线状态 | 临时数据，运行时自动重建 |
| 链接预览 / 资源缓存 | 可随时重新生成 |
| S3 侧资源与快照 | 体积大且生命周期独立，需用 S3 自身的备份策略 |
备份流程本身也很讲究：快照先写入私有暂存目录，最终归档以仅属主可读的权限原子性落盘，失败的备份绝不会用半截文件覆盖你已有的归档（见 backup.go 中的writeArchiveAtomically）。
一条命令创建备份：chatto backup 快速上手
备份时 Chatto 服务无需停止，命令通过chatto.toml里的客户端配置连接 NATS 即可。
推荐的最小自托管服务器「一体化」方案——加密归档 + 内置密钥，恢复最不容易出错：
chatto backup -c chatto.toml --encrypt --include-keys执行后会提示你输入并确认口令，生成的文件是带时间戳的backups/<timestamp>.tar.gz.age。
Docker Compose 部署则跑一个一次性容器即可（示例编排见 compose.yml）：
docker compose run --rm chatto backup --encrypt --include-keys💡 小提示：如果你用的是
chatto init生成的内嵌 NATS 配置，NATS 默认只进程内运行、不开 TCP 监听。执行 CLI 备份前需在chatto.toml中为[nats.embedded]打开port与bind_address = "127.0.0.1"。
age 加密详解：口令从哪里来、去哪里
--encrypt使用age这一现代文件加密格式，整份归档端到端加密，扩展名变为.tar.gz.age。
关键在于口令输入方式——Chatto 拒绝把口令写在命令行参数里（会泄漏进 shell 历史和进程列表），只提供三种安全入口：
- 交互式提示：手动运行时输入并确认
--passphrase-file /run/secrets/chatto-backup-passphrase：从受限权限文件读取，适合定时任务--passphrase-stdin：从标准输入显式读取，适合对接密钥管理系统
# 无人值守的定时备份 chatto backup -c chatto.toml --encrypt --include-keys \ --passphrase-file /etc/chatto/backup-passphrase -o /mnt/backups/chatto-daily.tar.gz.age由于采用标准 age 格式，你还能用独立的age命令行工具验证、手动解密或更换口令重新加密——归档不绑定 Chatto，永远不会被锁定。
⚠️务必记住：--include-keys意味着任何拿到归档的人都能解密全部消息正文与用户个人数据。凡是包含密钥的归档，必须同时--encrypt，并按敏感材料保管。
密钥分离策略：keys export 与 keys import
默认备份不包含密钥加密记录（KEK），这是刻意设计：数据归档被盗时，攻击者无法解密其中的消息。代价是恢复时必须能找到配套密钥。两种方式按需选择：
方式一：一体化备份（推荐小型服务器）
chatto backup -c chatto.toml --encrypt --include-keys方式二：数据与密钥分开保管（纵深防御）
# 1. 备份数据（不含密钥） chatto backup -c chatto.toml --encrypt -o data.tar.gz.age # 2. 单独导出 age 加密的密钥文件 chatto keys export -c chatto.toml -o keys.backup恢复时先还原数据，再导入密钥：
chatto restore data.tar.gz.age -c chatto.toml chatto keys import keys.backup -c chatto.toml导入逻辑只写入不存在的密钥引用、从不覆盖已有记录，因此可以安全重复执行（实现见 keys.go）。
恢复步骤：chatto restore 操作清单
恢复前务必停掉 Chatto：内嵌 NATS 场景下restore会自启一个临时 NATS 服务器写回数据；外部 NATS 场景则停应用、保持 NATS 运行。
# 1. 停止服务 docker compose stop chatto # 2. 恢复归档（自动识别 age 加密并提示口令） docker compose run --rm chatto restore /backups/2026-09-04T12-00-00Z.tar.gz.age # 3. 重启 docker compose up -d chatto⚠️ 不要用
docker compose down，那会把 NATS 一起停掉。
冲突处理通过--conflict控制（详见 restore.go）：
| 参数 | 行为 | 适用场景 |
|---|---|---|
--conflict=error（默认） | 目标流已存在则直接失败 | 全新服务器恢复 |
--conflict=skip | 跳过已存在的流 | 部分恢复 / 合并 |
--conflict=overwrite | 删除并重建已有流 | ⚠️ 破坏性全量覆盖 |
恢复还有内建安全边界：拒绝符号链接等非常规文件、拦截路径穿越、限制条目数与解压体积，防止畸形归档无限膨胀。
另外，保留相同的core.secret_key可以让可续期会话、OAuth 凭据等运行时凭据在恢复后继续有效；换一个值则是灾难恢复时一次性作废所有旧凭据的干净手段。
灾难恢复清单：照抄就能上生产
把下面这份清单贴在运维手册里：
- 频率：活跃服务器每日备份是合理起点，按你能容忍的数据丢失量调整
- 保留：常见模式是每日保留 14 天 + 每周保留 8 周；数据与密钥文件用同一保留窗口
- 异地：备份放到与数据不同的卷或远端对象存储——同盘备份防不了磁盘故障
- 加密：存到共享/远端存储的备份一律
--encrypt - 密钥：一体化
--include-keys或分离保管，二选一但必须有答案 - 演练：定期在独立环境恢复一份备份，验证口令有效、流程跑通
- S3：若资源走 S3，为其配置独立的备份与生命周期策略
📌一个容易踩的坑：备份不在账户删除流程之内。如果你恢复的旧备份里还包含某已注销用户的密钥，该用户的加密消息会重新可读。请让备份保留策略与合规义务匹配（见 backup-restore.mdx 中的详细说明）。
延伸阅读
- 官方备份与恢复文档：backup-restore.mdx
- 功能需求文档：FDR-040-backup-and-restore.md
- 加密体系背景（KEK/DEK 两级密钥与加密擦除）：encryption.mdx
- CLI 命令源码：backup.go、restore.go、keys.go
掌握「备份 → 加密 → 密钥分离 → 定期演练」这条主线，你的 Chatto 服务器就能从容应对任何一次硬件故障。🛡️
【免费下载链接】chattoA fully-featured team and group chat application that you can easily selfhost.项目地址: https://gitcode.com/gh_mirrors/chatt/chatto
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
