可靠发布专题 02｜从 SQLite 一致性备份开始

导语
在线备份（consistent backup）是保证 SQLite 数据库在不停服务时可恢复性的基础手段之一。本文在工程实践层面讨论在线备份的常用方法、如何结合完整性检查判定备份可用性，以及如何在隔离环境中验证恢复流程的边界条件和陷阱。目标不是覆盖所有工具细节，而是帮助有工程经验的读者形成判断标准和可重复的验证步骤。

在线一致性备份的基本方法与原理

SQLite 提供的在线一致性备份主要依赖两类技术思路：基于 SQLite 自身的备份 API（sqlite3_backup / Python 的 Connection.backup）以及文件层面的复制（包括复制主文件和 WAL/SHM 文件，或使用文件系统快照）。备份 API 的关键优点是它在逻辑页级别创建目标文件的一致快照，通常不需要暂停写入；文件层复制则更依赖外部一致性机制，比如在复制时确保 WAL 文件同步并可能做一次 checkpoint。

工程判断的第一条是：如果你能改变应用层的备份代码，优先使用 SQLite 的备份 API；如果只能在文件系统层面进行备份（例如由基础设施团队做快照），必须保证包括 -wal 和 -shm 文件，或在备份前完成 checkpoint，使主文件处于一致状态。备份 API 在大数据库上可以分批执行以控制延迟，但分批备份仍然要在目标上逐步写入并最终完成目标的校验。

完整性检查的实践与局限

SQLite 自带两类有用的完整性检查：PRAGMA integrity_check 和 PRAGMA quick_check，以及更专门的 PRAGMA foreign_key_check 来检查外键约束。实务建议是在每次备份完成后，首先在目标副本上运行 integrity_check 确认数据库页结构一致性，再运行业务层的简单查询集（例如关键表的行数或索引可达性）作为表层健康检查。

需要明确的是，integrity_check 能检测出页级别的损坏、索引与表的结构不一致等低层次问题，但并不能替代业务一致性验证。比如逻辑层面的约束缺失、应用级别的不可见竞态或历史数据语义错误，可能无法被该指令发现。再者，完整性检查本身需要读取整个数据库，耗时与 IO 成本不可忽视，因此在大数据库上应安排在低峰或异步校验池中执行，并配合恢复验证计划。

隔离恢复验证：原则与步骤

隔离恢复验证的核心是“用恢复文件做端到端的可用性测试，而不影响生产系统”。推荐的步骤是：1）在独立环境中把备份文件恢复到新的 SQLite 实例（只读挂载或新进程）；2）运行 PRAGMA integrity_check、PRAGMA foreign_key_check 等低层检测；3）执行预定义的业务回归用例，覆盖关键路径和关键查询；4）比对恢复后的数据摘要（例如关键表行数、重要索引的 top-k 结果或表级 checksum）；5）把验证结果归档并在出现异常时触发告警与人工审查。

复现频率应依据风险而定：对写入频繁且业务临界的数据库，建议每天至少做一次恢复验证；对归档类或只读分析库，可以降低频率。验证环境要能模拟生产读取负载的典型查询，以暴露索引缺失或统计信息偏差导致的问题。

恢复验证不是“跑一个 integrity_check 就万事大吉”，它是一个包含低层完整性检测与面向业务回归测试的整体流程。

常见误区与边界判断

• 误认为文件复制总是安全：直接复制主文件在 WAL 模式下是不够的，缺失 -wal 文件会导致数据丢失或不可恢复。判断边界时要核查数据库运行模式（WAL vs DELETE）并制定相应的复制策略。
• 误用 VACUUM 作为备份手段：VACUUM 用于重写数据库以回收空间，但在生产环境运行需要独占访问，作为常规备份手段代价太高。
• 盲信 checksum 覆盖一切：对备份文件做 SHA256 等哈希可以检测传输中损坏，但哈希是在备份完成后才有意义，不能替代备份过程中的一致性保障。
• 忽视并发影响：备份 API 在执行过程中会以读事务形式访问源库，长时间的备份可能保持对某些资源的占用，从而与应用写事务发生竞争。实践中应把备份拆成小块执行并合理处理 BUSY 响应。
• 以为 integrity_check 检测所有逻辑错误：它主要验证物理结构与索引的一致性，业务层语义错误、外部依赖的缺失仍需业务回归测试发现。

实践建议与可操作步骤小结

• 设计备份策略时优先使用 sqlite3_backup 或语言绑定提供的 backup API，分批量、可中断地复制页面，以控制对生产的影响。
• 如果采用文件系统快照，在触发快照前要先执行 checkpoint 或确保 WAL 文件一并快照。
• 每次备份完成后，在隔离环境运行 integrity_check 和若干业务回归查询，并把结果与历史基线比对；对关键表计算可重复的摘要以便快速比较。
• 对大规模数据库，把完整性检查与业务回归分阶段执行：先做快速健康检测（quick_check、行数、索引抽样），在资源允许时再做全表完整性检查。
• 自动化错误处理：备份失败、完整性检查异常或恢复验证不通过时，应触发警报并将备份标记为不可用，避免自动覆盖上一次可用备份。

延伸阅读

• SQLite Documentation: https://www.sqlite.org/docs.html
• Python Documentation: https://docs.python.org/3/