我做了次备份恢复演练，才发现备份文件是空的

上个月做了一次数据库恢复演练，本来以为走个流程，结果第一关就卡住了。

我们那套库每天凌晨自动备份，脚本跑了两年，日志里天天写着「备份成功」。我随手挑了个三天前的备份包，解压、导入，一套动作行云流水，然后报错说文件损坏。

换了一个，还是损坏。又换了上周的，一样。

翻回备份脚本才发现问题：它先执行导出，然后把导出文件打包。但导出命令是异步的，脚本没等它写完就开始打包了。凌晨机器负载低的时候导出很快，脚本侥幸能跑通；一旦那天数据量稍大，导出的文件还在写，打包程序已经把当时那点内容收进去了。

所以「备份成功」这四个字，只是说打包命令退出码是 0，跟包里有没有东西一点关系都没有。

后来改了三处。

第一，导出改成同步等待，拿到明确的完成状态再往下走。第二，打包前检查文件大小，小于阈值就直接报错退出，让告警响起来。第三，备份完成后自动做一次校验：解压出来，尝试连一个临时库，能建表能查数才算过。

还有一条是演练本身带来的：我把恢复演练排进了每季度一次，用最新备份在隔离环境完整恢复一遍，记录耗时和数据量。以前觉得这是形式主义，现在觉得不做这一步，等于不知道自己有没有备份。

顺带说一个容易忽略的点：备份文件别只放一份在同机房。那次演练还有个插曲，我想试试异地那份，结果发现同步任务半年前就断了，因为存储桶密钥换过一次没人更新。备份没报错，同步也没报错，因为那个任务早就不在任务列表里了。

现在回头看，备份这件事的关键不是「有没有跑」，而是「跑出来的东西能不能用」。这两个问题的答案，只有真的恢复一次才知道。