「我们每天都备份」是很多企业对自己数据安全的回答。但真要用到备份的时候，能顺利恢复出来的比例往往没这么乐观。问题通常不出在"没备份"，而出在备份失败得太安静：任务照常结束，文件照常躺在目录里，只有解压或恢复的那一刻才会暴露。

下面三个验证环节，是我们排查自己备份时踩出来的，写下来给同样把备份当"已经做过的事"的团队参考。

一、一个"每天成功"的备份，是怎么骗过所有人的

先看一段很多人写过的备份命令：

mysqldump -u用户 -p密码 数据库 | gzip > /backup/all_$(date +%F).sql.gz

它看起来很正常。但如果 mysqldump 因为权限不足、某张表损坏、磁盘写满而失败，它会往标准错误打印报错并返回非 0 退出码；而在这条管道里，Shell 默认取的是后一个命令（gzip）的退出码——gzip 老老实实把一段空数据压缩好了，于是整体返回 0。

结果就是：脚本报告成功，文件也确实生成了，只是这个文件解压出来什么都没有。如果脚本再顺手把 mysqldump 的错误输出丢进 /dev/null，那仅有的线索也一起丢了。

这就是静默失败的特征：过程中的每一步看起来都对，只有结果不对。而备份偏偏是"平时没人看、出事才看"的东西，所以它能安安静静地坏上几个月，直到某天真的需要它。

二、三个必须亲手验证的环节

1. 看退出码，不要看文件在不在

判断备份成功与否，优先相信退出码，而不是"目录里多了一个文件"。

  • Shell 脚本开头加 set -o pipefail，让管道里任何一个命令失败都算整体失败。
  • 更稳妥的做法是先导出到临时文件、压缩、校验，全部通过再移动到正式目录，避免半成品混进备份列表。
  • 不要把错误输出直接丢掉。哪怕不打印到终端，也请留下末尾几百字节到日志里——排查时这几百字节往往就是全部信息。

2. 校验产物，而不是只看它生成了

退出码正常不代表文件可用，磁盘写满就可能导致文件被截断。

  • 设一个体积下限。先观察几次正常备份的大小，取一个明显低于正常值的阈值。我们的库备份稳定在 6.5MB 上下，阈值就设在 1MB，低于它一律当作失败。
  • 能校验就校验。gzip 可以用 gzip -t 检查完整性，SQL 文件可以取头部若干行看有没有正常的导出语句。
  • 把这些校验写在备份脚本里，失败就删掉坏文件——留着它比没有更危险，因为列表里看不出区别。

3. 真恢复一次，才算数

前两步只能证明"文件看起来没问题"。备份能否恢复，只有恢复过才知道。

  • 找一台与生产隔离的机器，或者一个临时库，把备份导进去。
  • 记录整个过程花了多久——这个时间就是你在真出事时的恢复时长（RTO）参考值。很多人是做了这一步才发现，恢复比想象中慢得多。
  • 把恢复演练变成周期性动作，写进运维日历。只做过一次的演练，和没做过的差别会随着时间缩小。

三、备份放在哪，决定了它有没有用

把备份文件和数据库放在同一块磁盘上，等于没有备份。磁盘损坏、误删目录、被勒索软件加密——这些场景下，备份会跟着数据一起消失。

  • 至少留一份异地副本：内网的另一台机器、NAS，或者对象存储都可以。关键是它不能和生产服务器共用同一块盘、同一台机器。
  • 保留多份历史：只保留一份的话，如果数据是三个月前被慢慢改坏的，你恢复出来的仍然是坏数据。建议至少保留 7 到 14 天，并且能回答"昨天、上周、上个月各有一份吗"。
  • 注意备份文件本身的权限：全库备份里包含全部业务数据，它的敏感级别等于甚至高于生产库。放在共享目录、权限设成所有人可读，就是把风险换了个地方。

四、让失败主动找上门

前面三步解决的是"备份是否可信"，这一步解决的是"坏了多久你才会知道"。

  • 失败必须主动通知，写日志不算通知。邮件、企业微信、钉钉群机器人都可以，重点是它会出现在你每天会看的地方。
  • 再加一条新鲜度检查：检查"备份目录里有没有 26 小时内生成的文件"。它能覆盖脚本压根没被执行、定时任务被删掉这类情况，这是备份脚本自己汇报不了的。
  • 这个新鲜度检查要独立于备份任务之外触发。如果它挂在备份流程里，备份没跑，检查也不会跑，等于自己检查自己。
  • 部署完记得用一次测试通知验证通道是通的。通知配置写错但没人发现，是很常见的翻车方式。

五、按规模落的清单

规模建议动作
单台服务器的小型站点每日全库备份 + 体积校验 + 下载一份到本地或网盘 + 每月恢复一次
多台服务器的业务系统在上面基础上加异地同步、保留 14 天、备份失败告警、新鲜度检查
有合规要求的业务再加备份加密、访问审计、恢复演练记录归档，并明确谁对备份结果负责

六、小结

回到开头那句话。备份的价值不在于"每天有一个文件生成"，而在于"需要的时候能拿回来"。这两件事之间隔着三个动作：校验退出码与产物、留一份异地副本、真正恢复一次。

如果你现在不确定自己的备份能不能恢复，比较省事的起点是：打开备份目录，挑一份日期较新的，试着解压看看里面有没有数据。这一步通常只需要几分钟，但它能立刻告诉你，过去这些天到底有没有在真正备份。

如果你正在整理上线流程，可以对照网站上线前检查清单逐项过一遍，备份与恢复演练也在那份清单里；需要为恢复演练准备一台隔离机器，配置估算方式可以参考服务器怎么选。