SQLite 不是问题，没有备份流程才是问题

很多个人博客在早期完全可以继续使用 SQLite。它部署简单、维护成本低、迁移也方便。真正的风险通常不是 SQLite 本身，而是站长以为“复制一下 database.db 就算备份”。等到误删文章、磁盘损坏或迁移服务器时，才发现备份文件不完整、路径不对、压缩包打不开，甚至根本没有测试过恢复。

一个可靠的备份流程至少包含四件事：固定备份位置、保留多个版本、校验文件可读、定期恢复演练。只做第一件事，不能算完整备份。

先明确要备份什么

博客系统的数据不只在数据库里。SQLite 数据库保存文章、分类、标签、用户、评论和广告配置；上传目录保存封面图、正文图片和附件；.env 保存运行环境变量。真正迁移或恢复时，三者缺一不可。

建议把备份范围固定为：数据库文件、static/uploads/ 目录、生产环境配置文件。配置文件里有密钥，备份要放在服务器私有目录，不要进入公开下载路径，也不要提交到代码仓库。

校验比备份更重要

备份生成后要做基本校验。第一，压缩包是否存在且大小合理。第二，能否列出压缩包内容。第三，SQLite 文件能否打开并执行简单查询。第四，上传目录中是否包含最近上传的图片。

如果只看脚本返回成功，很容易漏掉权限问题。例如 cron 下运行的用户和手工运行的用户不同，手工测试能写入 /var/backups，定时任务却没有权限。

恢复演练怎么做

恢复演练不要直接在生产环境覆盖文件。更稳妥的方式是在临时目录解压备份，启动一个临时应用实例或用本地环境读取数据库，确认首页、文章详情、后台登录和图片路径都正常。

演练时重点检查三类页面：最新文章是否存在；带图片的文章是否能显示；后台配置是否保留。广告配置、站点标题、联系邮箱、ads.txt 这类内容也在数据库里，恢复后要一并确认。

保留策略要克制

小站不需要无限保留备份。可以采用简单策略：最近 7 天每天一份，最近 4 周每周一份，最近 6 个月每月一份。这样既能应对短期误操作，也能避免备份占满磁盘。

备份最好放到另一块存储或对象存储。只放在同一台服务器上，能防误删，但防不了整机磁盘故障。

总结

SQLite 适合个人博客冷启动，但备份必须流程化。备份文件、上传目录和配置要成套保存；每次备份后要校验；每隔一段时间要恢复演练。真正可靠的不是“我有一个备份文件”，而是“我知道它能恢复”。