备份任务显示成功，甚至仓库校验也通过，是否就能说“系统可恢复”？最近整理自己的长期运行数据时，我专门从一份加密快照里取出一份 SQLite 数据库，在隔离位置打开并核对。结果令人放心，但只能在一个明确的范围内放心：这份库在那个快照里可读，不等于整套系统已经能恢复。
问题不在“有没有备份”，而在证明对象被偷换
一次备份至少有四个不同的问题：任务是否写完、仓库是否还能读、指定文件是否能从指定快照还原、恢复后的应用能否按预期工作。前两项属于备份链路，第三项才触及具体数据；第四项还要依赖配置、依赖程序、其他数据库、附件和运行环境。不能用第一项的绿灯代替后面三项。
这次我没有改动现行库，也没有把整个系统导回生产。先固定要检查的快照和目标文件，在私有隔离目录取出单库副本；再检查副本是否能被 SQLite 打开、执行 PRAGMA quick_check，最后核对关键表的记录量和业务对象是否存在。恢复后的库与比较时点的现行库核对一致，临时明文副本随后清理。这是一次指定对象的隔离恢复，不是整机演练。
“库能打开”仍有两层边界
第一层是完整性检查的能力边界。SQLite 官方说明，quick_check 为加快检查，不验证 UNIQUE 约束，也不验证索引内容与表内容是否一致。因此它给出 ok，只能说明它覆盖的检查没有发现问题；关键业务关系仍应另查，必要时使用更全面的检查。本文没有把一次快速检查写成所有数据语义正确的证明。
第二层是时间边界。备份快照与现行库不是永恒同步的两个副本。即使某个比较时点记录数一致，后续写入也会立即改变状态。需要回滚时，应重新确定恢复目标的时点和从那个时点之后发生的写入，而不是拿昨天的“相等”承诺今天零损失。
我会怎样给备份结果下结论
- 有备份：能指明备份任务、对象和完成时点，但还没有证明可还原。
- 仓库可读：能从备份介质读取记录，仍需恢复真实对象。
- 单库已隔离恢复：从指定快照还原指定库，按文件、数据库和业务对象核对；结论只覆盖这份库和该时间点。
- 整套服务可恢复：还需要覆盖其他数据、配置与依赖，并在可控环境走过真实启动和关键操作。没有执行就不要打勾。
我这次得到的是第三层的证据，而不是第四层。这个区分看似咬文嚼字，实际决定了下一次故障时我们会不会错误地以为“备份已验证”就能直接恢复业务。
小系统也能做的最小演练
先列清楚最重要的一个数据对象和它所属的备份快照，在不触碰现行业务的隔离位置还原；确认对象可读、关键记录能查到，并把未覆盖的文件、配置和恢复时点写明。真实需要整机恢复时，再单独安排全链路演练。不要为了做一次小验证就覆盖在线库，也不要因为没有做全链路，就放弃验证任何对象。
这篇文章由作者的实际隔离恢复记录与 AI 辅助整理而成；涉及私人系统的名称、目录、拓扑和数据量已省略。结论只对应已核对的备份对象和当次时点，不宣称整机恢复已完成。
一手资料
- SQLite 官方文档：PRAGMA quick_check 的检查边界（核对于 2026 年 9 月 30 日）。
- restic 官方文档：从指定快照恢复到目标目录（核对于 2026 年 9 月 30 日；具体命令取决于实际备份对象，不代表本文做过整机恢复）。
