把备份脚本从“能跑”改到“敢恢复”

我以前判断备份是否可靠，只看定时任务有没有报错。直到一次迁移才发现，压缩包里缺了数据库导出文件——脚本仍然以 0 退出，因为最后执行成功的是上传命令。

先定义要恢复什么

“备份整台服务器”听起来保险，实际常常难以恢复。更清晰的做法是列出服务重建所需的最小集合：配置文件、持久化数据、数据库转储、密钥，以及能重现软件版本的清单。

• 数据库使用一致性导出，不直接复制运行中的数据目录；
• 容器配置保留 compose 文件与明确的镜像版本；
• 密钥单独加密保存，并记录恢复时的权限要求；
• 缓存、日志和可重新生成的构建产物默认不进入备份。

让错误尽早暴露

Shell 脚本至少开启严格模式，并在上传之前检查预期文件存在且非空：

set -euo pipefail

test -s "$workdir/database.sql"
tar -C "$workdir" -czf "$archive" .
sha256sum "$archive" > "$archive.sha256"

校验和不能证明业务数据正确，但可以证明文件在传输和存储后没有悄悄变化。远端上传完成后，最好重新下载校验文件并抽样比对。

保留策略要对抗“晚发现”

只保留最近七份日备份，无法处理两周后才发现的数据污染。我采用简单的分层策略：保留 7 个日版本、5 个周版本和 6 个月版本。数量不必照抄，关键是覆盖问题被发现的时间窗口。

恢复演练是备份的一部分

每月在隔离目录或临时实例中执行一次恢复：解密、校验、解压、导入数据库、启动服务，再用一个最小检查清单验证登录、读取和写入。演练的命令与耗时也记录下来。

没有恢复步骤的备份，只是一批希望有用的文件。

最后让通知包含可判断的信息：生成时间、文件大小、校验结果、远端位置和最近一次恢复演练日期。这样“成功”才不只是一个绿色图标。