小服务的备份，要从恢复开始检查
我以前会盯着备份目录的大小看，文件每天都在增长，就觉得没问题。后来在另一台机器上恢复一个小工具，才发现数据库在，上传的附件却没备份，配置文件里还写着旧机器的绝对路径。
先写一张恢复清单
对一个带数据库的小服务，我现在至少列出四项：程序版本、配置、数据库和用户上传的文件。程序通常能重新下载，但版本号要记下来；配置中的口令不放进公开仓库，和数据一起保存在限制访问的备份位置。
SQLite 服务运行时，如果使用 WAL 模式，直接复制主数据库文件可能漏掉还在 WAL 中的数据。可以使用 SQLite 的备份接口，或在维护窗口停止写入后再复制。不要把“复制到了文件”当成“复制到了完整数据库”。
恢复演练用空目录
我会建一个新目录，把备份解开，按记录的版本启动程序，再检查几条最近的数据和一张附件。测试服务只监听本机地址，避免和正在使用的服务抢端口。能打开首页还不够，也要试一次写入。
- 检查最新记录的时间，确认备份没有停在几天前。
- 检查文件所有者，避免恢复后程序读不到配置。
- 记录实际恢复耗时，而不只记录压缩包大小。
让失败足够明显
备份脚本中途出错就应返回非零。上传失败时，不要继续删除本地最后一份可用备份。我保留近期每日副本和较少的月度副本，但会先确认新的副本可读，再清理旧文件。
这些步骤不复杂，真正容易遗漏的是定期做一次。我的做法是在每次大版本升级前恢复一遍，顺便检查那份恢复笔记是否还写得明白。