SQLite 备份为什么不能只复制数据库文件

看到一个数据库文件，很容易把备份理解成“定时复制这个文件”。对于正在运行的 SQLite，这个动作需要更多前提；对于一个带有图片、附件和发布历史的网站，数据库也只是需要保留的一部分。

备份真正要回答的问题是：能否在另一处重新得到一个一致、可继续维护的站点？

先取得一致的数据库状态

在 WAL 模式下，已经提交的变化可能还在 WAL 文件中，而没有合并回主数据库。把一个正在使用的主文件单独复制出去，不能当作完整备份方案。

SQLite 提供在线备份接口，用于从源数据库得到一致的目标数据库。实际实现仍需要处理占用、失败、磁盘空间和完成结果，不能只因为目标文件存在就宣告成功。

备份时也不应为了图方便，把数据库连接、日志和密钥文件一股脑放进一个对外下载目录。

保存内容所引用的文件

文章正文可能在数据库里，配图和附件却位于独立存储。只恢复正文，就会得到一组图片失效、附件打不开的页面。

因此，备份清单需要覆盖私有原件、被保留的处理产物、活动发布包以及维护历史所必需的文件。每份文件记录相对路径、大小和摘要，恢复前先核对清单与实际字节。

运行秘密则通过独立运维渠道保管。内容迁移包和系统备份是不同用途，不应该因为都使用压缩归档，就把它们视为同一件事。

恢复到新目录，再检查

直接覆盖唯一的运行目录，会让恢复失败和现有故障叠在一起。更容易控制的方式是在新目录恢复，验证通过后，再按明确步骤切换。

检查不止是数据库能够打开。至少需要实际读取公开文章、打开私有素材、下载附件、登录后台、编辑一份草稿，并完成一次正常发布。

旧会话是否仍然有效、未完成任务如何处理，也需要事先规定。恢复数据不应无声恢复已经不该继续使用的访问凭据。

用恢复结果评价备份

备份任务可以报告生成时间、大小、摘要和失败原因；这些信息说明备份过程发生了什么。真正证明它可用的，是从这份备份恢复后的实际操作。

保留策略也要在此基础上执行。删除前先列出准备移除的对象，确认当前包、被引用的原件和有效任务不会被一起清掉。出现不完整清单或摘要错误时，应停止执行，留下可核对的原因。

一个体积很小但缺少素材的归档，和一个很大却从未恢复过的归档，都不能仅凭大小判断质量。备份最终保住的，应当是能够重新使用的内容和维护能力。

参考：SQLite Online Backup API、SQLite Write-Ahead Logging。上述站点文件清单、会话撤销与新目录切换属于本站恢复策略。