备份任务天天绿，真换一台小鸡能恢复吗？自建服务恢复演练清单

自建服务的备份很容易做到“每天有个压缩包”。但真遇到小鸡失联、磁盘坏掉或重装系统，需要回答的是：换一台机器后，多久能把服务和数据恢复出来？

建议给备份加一个验收动作：在隔离环境里实际恢复一次。下面以普通 SQLite 数据库、上传目录和 Docker Compose 部署的小服务为例，整理一份能落地的演练清单。

最多能丢多久的数据（RPO）：能接受丢一天，还是只能丢一小时？每天备份一次，成功运行且及时完成时，也可能损失接近一天的数据。任务漏跑或延迟还会扩大这个窗口。
最多能停多久（RTO）：恢复目标是半小时、两小时，还是次日？下载速度只是其中一部分，还要算上开机、安装、配置、校验和切换入口。

举个假设：需要下载 20GB，实际持续速度只有 10MB/s，光传输就约 33 分钟。若目标是半小时内恢复，方案在下载这一步就已经不够了。

除了数据库和上传文件，还要包含部署配置、必要的环境变量、镜像版本或构建材料，以及恢复时要用的密钥。只保留 compose.yaml，却漏掉 .env 和数据卷，换机器时仍然可能卡住。

密钥和环境变量应加密保存；解密备份所需的密码，以及存储账号的恢复方式，也应有不依赖原 VPS 的副本。不要等原机没了，才发现密码文件只存在原机上。

普通 SQLite 可以通过 CLI 的 .backup 生成一致的数据库副本。下面的路径都是示例，需要换成实际路径，并确保运行用户有对应权限：

install -d -m 700 /var/backups/myapp
sqlite3 -readonly /srv/myapp/data/app.sqlite \
  ".backup '/var/backups/myapp/app.sqlite'"

源数据库用只读方式打开，也能避免路径写错时意外新建一个空库。只有导出成功，才进入后续备份；失败应告警，不能继续把旧导出文件当作今天的新备份。相关机制见 SQLite Backup API 和 CLI 说明。

这里的一致性只覆盖这份数据库。如果数据库记录和上传文件必须互相对应，还需要应用提供的备份机制，或在维护窗口暂停相关写入后一起备份。数据库、附件、其他数据库之间，不会因为各自“备份成功”就自动处于同一时间点。

假设已经准备好一个位于另一台机器或存储服务的 restic 仓库，并配置好了 RESTIC_REPOSITORY、仓库密码及访问凭据。先备份示例服务需要的文件：

restic backup \
  /srv/myapp/compose.yaml \
  /srv/myapp/.env \
  /srv/myapp/uploads \
  /var/backups/myapp \
  --tag myapp

路径需要按自己的部署调整，先列清单再执行，不能照抄目录。记录退出状态与快照 ID，并对失败或部分文件读取失败告警。备份文档

再到一台测试机，或隔离的演练环境里选择快照：

restic snapshots --tag myapp
restic ls SNAPSHOT_ID
restic restore SNAPSHOT_ID --target /srv/restore-drill

SNAPSHOT_ID 要替换为确认过的快照 ID。核对快照的主机、时间、标签和路径；多个服务共用仓库时，直接恢复 latest 容易拿错。目标目录应是专门准备的空目录，演练恢复先不覆盖生产目录。恢复文档

上面的备份使用绝对路径，恢复后会保留路径层级，所以 SQLite 副本在示例目标目录下的位置是：

sqlite3 -readonly \
  /srv/restore-drill/var/backups/myapp/app.sqlite \
  'PRAGMA integrity_check;'

integrity_check 返回 ok 说明这项数据库结构检查通过，但它不验证业务数据是否齐全，也不替代外键检查。还需要抽查最近的记录、附件与应用功能。SQLite 检查说明

restic check
restic check --read-data

普通 check 主要检查仓库结构；--read-data 还会读取备份数据验证完整性，会增加耗时和远端读取流量。按仓库规模安排频率即可。仓库校验文档

文件恢复完后，在隔离环境启动应用，至少验证登录、最近的数据、附件下载和必要的一次写入。演练时要停用真实邮件、Webhook、定时任务等外部动作，避免测试实例重复发送通知或修改外部数据。

最后留一条记录就很有用：

快照时间 / 恢复的数据范围 / 下载耗时 / 启动耗时 / 缺失项 / 功能验收结果。