SQLite 开着 WAL，备份就不能只复制主文件

SQLite 的便利常让备份看起来也像“复制一个文件”。但在 WAL 模式下，最近提交的事务可能仍在 -wal 文件里。运行中只复制主数据库，得到的副本可能缺少已提交的数据。

使用数据库提供的一致性备份

在线备份 API 会生成一个一致的数据库快照。SQLite 命令行的 .backup 命令是常见入口。下面使用示例路径；目标目录应提前创建，并只允许备份账户访问。

sqlite3 /srv/app/data.db ".backup '/srv/backup/data-snapshot.db'"
sqlite3 /srv/backup/data-snapshot.db "PRAGMA integrity_check;"

检查应返回 ok。这验证数据库结构，却不保证业务数据符合预期。还应查询最近记录数量、关键配置和时间范围。大型数据库备份可能与写入争用资源，应测量时长并安排在低峰期。

备份不等于可恢复

把副本放到隔离目录，启动一个不会连接生产外部服务的测试实例，再核对应用是否能读取数据。不要直接把备份覆盖到正在运行的生产数据库上；旧 WAL 与连接状态会让恢复更加复杂。

1. 记录应用版本、数据库版本和配置依赖。
2. 在独立环境检查数据库完整性与关键业务查询。
3. 演练停止应用、替换数据库、修复属主权限和重新启动的流程。
4. 记录实际恢复时间，而不是只记录备份任务的退出码。

留住足够多的历史

保留多个时间点可以应对延迟发现的误删除。保留周期应由可接受的数据损失决定，并考虑磁盘容量。至少保留一份位于不同故障域的副本；同一块磁盘上的多个文件无法应对磁盘损坏。

权限与告警也是备份的一部分

数据库往往包含令牌、账号和私有配置。备份应设置严格权限，传输与异地存储应加密。监控最后一次成功时间、文件大小异常以及恢复演练结果，避免“定时任务还在，但备份早已不可用”。

参考：SQLite WAL、Online Backup API。