ObjectOS备份与灾难恢复
备份什么、如何恢复，以及如何为故障做规划。
备份与灾难恢复
ObjectOS 本身是无状态的 —— 运行时可从容器镜像重建。备份关心的是 ObjectOS 所依赖的数据，而不是 ObjectOS 本身。 围绕这些数据集来规划 恢复。
备份什么
| 资产 | 归属方 | 备份策略 |
|---|---|---|
| 业务数据库 | 客户 | 数据库原生备份（托管服务使用 PITR）;每季度测试恢复一次 |
编译产物（objectstack.json） | 应用/发布团队 | 每个发布的产物保存在不可变存储中;切勿覆盖 |
| Secret 基线 | 客户的密钥管理器 | 厂商原生备份;按策略轮换 |
对象/文件存储（启用 storage 能力时） | 客户 | Bucket 版本化 + 如需可跨区域复制 |
| 客户自管的身份提供方 | IdP 厂商 | 厂商原生 |
ObjectOS 不需要对其容器文件系统做单独备份。缓存目录
（OS_CACHE_DIR）可以重建。
数据库备份
按驱动匹配策略：
| 驱动 | 推荐方式 |
|---|---|
| PostgreSQL | 持续 WAL 归档 + 基础备份;支持时间点恢复 |
| MySQL | 二进制日志归档 + 完整转储;支持时间点恢复 |
| MongoDB | 副本集快照;通过 oplog 实现 PITR |
| SQLite（单节点 / 桌面） | 启用 WAL 模式 + 用 VACUUM INTO 或 Online Backup API 做热快照;如需更低 RPO 可叠加 Litestream 持续复制 —— 见下方 SQLite 部署 |
无论使用哪种驱动，都需验证：
- 备份能在客户的 RPO 内完成;
- 一个全新数据库能基于同一份产物启动 ObjectOS 并对外服务;
- 至少每季度执行一次端到端的恢复演练。
SQLite 部署
SQLite 是默认驱动，对于单节点形态的 ObjectOS 完全可以用于生产 —— 桌面端应用、小团队内部工具、边缘 / 本地一体机、评估环境。它的 取舍是结构性的：SQLite 是单写者，因此不适合多节点 ObjectOS、高并发 写入或共享数据库的部署。这些场景请使用 PostgreSQL。
当你确实在生产中使用 SQLite 时，让它稳定运行的配置和备份方案是配套的：
运行时配置
- 启用 WAL：
PRAGMA journal_mode=WAL（读不阻塞写;崩溃安全）。 PRAGMA synchronous=NORMAL是桌面 / 单机生产的常用默认值 —— 在 WAL 下安全，且比FULL快得多。- 数据库文件放在本地磁盘上。不要放在 NFS、SMB，或者在运行时 正在使用的情况下放在被 Dropbox / OneDrive / iCloud 同步的目录里 —— SQLite 的文件锁在这些位置不可靠，这是 SQLite 部署最常见的损坏 原因。
热快照（无需停机）
运行时继续对外服务的同时，可以用 SQLite 的 Online Backup API 或
VACUUM INTO 生成一致性快照：
VACUUM INTO '/var/backups/objectos/db-2026-05-27T13-00Z.sqlite';按照你的 RPO 节奏用 cron、systemd timer 或运行时内置 scheduler 触发。 给每份快照打上当时所用的产物版本标签，以便将数据库和产物作为一组 回滚（见下方 产物版本化）。
异地副本
本地快照扛不住磁盘故障。把每份快照推送到可持续存储：
- 服务器 / VM：推到 S3 或任何 S3 兼容 bucket（你大概率已经为
storage能力配过一个了）。 - 桌面端应用：把快照写入用户控制的同步目录（OneDrive / iCloud / Google Drive）—— 这里可以接受，因为快照文件是关闭且不可变的， 和活动数据库不同。
持续复制（更低 RPO）
在不放弃 SQLite 的前提下要拿到分钟级以下的 RPO，把 Litestream 与 ObjectOS 进程一起跑。它把 WAL 流式复制到 S3 兼容存储，并支持时间点恢复。当单节点 SQLite 部署需要 近零数据丢失时，这是推荐路径。
恢复
停掉运行时，用选定的快照替换数据库文件（或执行 litestream restore），用产生该快照时所对应的产物版本重新启动运行时。
产物版本化
把发布的产物视为不可变。给每份产物打上其编译所用的发布 id 标签
（例如 objectstack-2026-05-24.json）。恢复到已知正常的业务状态通常意味着：
- 将数据库恢复到所选时间点。
- 将 ObjectOS 指回当时在线的那个产物版本。
- 重启运行时。
如果就地覆盖产物，即便数据库备份完美无缺，也会失去干净回滚的能力。
RPO/RTO 规划
客户部署可行的起点目标：
| 等级 | RPO | RTO | 备注 |
|---|---|---|---|
| 评估 / 演示 | 尽力而为 | 尽力而为 | SQLite 快照即可 |
| 桌面端应用 / 小团队单节点 | ≤ 1 小时（快照）或 ≤ 秒级（Litestream） | 分钟级 | SQLite + WAL + 定时 VACUUM INTO + 异地副本 |
| 单租户生产 | ≤ 15 分钟 | ≤ 1 小时 | 托管 PostgreSQL + PITR + 热镜像 |
| 多租户 / 受监管 | ≤ 5 分钟 | ≤ 30 分钟 | 高可用数据库 + 多可用区 ObjectOS + 经过演练的 runbook |
更严苛的目标需要在 ObjectOS 容器之外做平台层改造（HA 数据库、多 可用区入口、热副本）。
值得演练的故障模式
- 数据库长时间不可用。 确认运行时返回明确的 503，并且探针正确 地把 Pod 标记为不健康。
- 产物回归。 回滚产物指针;数据不受影响。
- Secret 轮换。 轮换
AUTH_SECRET会使所有会话失效。请在维护 窗口执行，或在副本之间分批进行。 - 区域故障。 如果客户要求区域级故障切换，业务数据库、密钥 管理器和入口都需要跨区域。ObjectOS 本身可以运行在任何能拉到 镜像的地方。
runbook 中应记录的内容
- 每个数据集的备份计划、保留策略和值班联系人。
- 分步恢复流程（先恢复数据库，再切换产物，最后启动 ObjectOS）。
- 用于确认已恢复数据库一致性的校验查询。
- ObjectOS 镜像和产物版本各自的回滚方案（见 升级与回滚）。
- 面向客户的事件沟通模板。