SQLite 备份和迁移，两步别搞反
SQLite 有个让人放松的特点：整个数据库就是一个文件。但也正因为这样，很多人直接把文件复制走当备份，然后在某天发现复制出来的那份是坏的。SQLite 数据怎么备份和迁移，关键是别在别人正在写的时候动那个文件。
一、先给结论
备份和迁移用的是同一个前提：你要拿到的是一份一致的快照，不是一份时间点混乱的文件。
服务在跑的时候直接复制，可能只复制到已提交的一部分页。文件看着在，打开却报损坏。所以顺序是先保证一致性，再谈搬运。
这个问题在小项目里特别容易被忽略，因为数据量小、复制得快，出问题的概率看着不高。但「概率不高」和「不会发生」是两回事，一旦发生在你自己身上就是全部。
所以我建议把备份当成一个固定动作，而不是出事前的临时操作。
二、第一步：把备份和迁移分成两件事
很多人把这两个动作混在一起做，结果出问题时不知道是哪一步错了。
备份是「留一份现在的样子」，迁移是「让它在另一台机器上跑起来」。备份的目标是能恢复，迁移的目标是能启动。
具体动作：先定下备份放哪、留几份，再去想迁移。顺序反了，迁移过程中出错就没有退路。
三、SQLite 数据怎么备份和迁移：先拿一份一致快照
不要用文件复制命令去拿运行中的数据库。
SQLite 提供了在线的备份接口，能在服务运行的同时导出一份一致的数据；命令行工具也有对应的导出方式。这些方式会正确处理正在进行的写入。
具体动作：把备份写成一条固定命令，别每次手动敲。手动做事迟早会漏。
规则细节上，以 SQLite 官方文档的口径为准，不同版本的参数名有变化，不要照搬旧教程。
四、第三步：迁移前先在目标机器上还原一次
这是最容易被跳过的一步：备份文件生成出来，从来没人试着还原过。
做法很简单，在目标机器上把备份还原成一个临时库，跑几条查询确认数据在。只有还原成功过的备份才叫备份。
具体动作：在目标机器上还原一次，并连上你的程序跑一遍最常用的那条查询。
五、第四步：迁移时先停写，再换文件
切到新机器的那一刻，必须保证老机器不再写。
做法是先停掉写入入口，确认没有正在进行的事务，再复制文件过去。带写入状态的文件搬走，新老两边都会有问题。
具体动作：写一个停机检查清单，包含「确认无进行中的写事务」这一条。
六、第五步：留下回退的路，并检查两个常见卡点
切换之后老文件不要马上删。
如果新机器上启动失败，你需要能立刻切回去。删除这一步留到最后确认无问题之后再做。
具体动作：迁移完成后保留原文件一段时间，确认稳定了再清理。磁盘便宜，返工很贵。
另外两个卡点提前说一下。一是备份文件大小跟原文件差很多，可能是用了逻辑导出而不是物理快照，两者结果不同，看你需要哪种。
二是迁移后发现自增 ID 或时间字段对不上，多半是导出时用了带时区差异的方式，或者程序里有依赖本地时间的逻辑。
常见问题
Q：SQLite 能不能直接复制文件做备份？
A：服务停止、确认没有写入时可以直接复制。服务在跑的时候要用数据库提供的备份方式，否则拿到的可能是不完整的文件。
Q：备份多久做一次合适？
A：取决于你能接受丢多少数据。先想清楚这个容忍度，再倒推频率，而不是照搬别人的周期。
Q：迁移到新机器后程序连不上，先查什么？
A：先查文件路径和权限，再查驱动版本。路径写错和权限不足是这类问题里最常见的两个原因。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」