凌晨三点接到运维电话，说昨晚的数据库备份文件打不开——这种事你遇到过吗？备份文件损坏不是小概率事件，存储介质老化、网络传输中断、甚至杀毒软件误删，都可能让辛辛苦苦做的备份变成一堆乱码。
问题在于，大多数人只关注“有没有备份“，从来不验证“备份能不能用“。等到真要恢复的时候才发现文件已经废了，那就晚了。所以今天聊两个核心问题：怎么提前发现备份文件有问题，以及发现之后还能不能救回来。
一、数据完整性校验：三道防线
第一道防线是哈希校验。备份完成后立即计算文件的MD5或SHA-256值，记录在单独的日志文件里。下次校验时重新计算一次，两个值不一致就说明文件被篡改或损坏。这个操作可以写成脚本，每天定时跑，十分钟就能完成几百GB文件的校验。
第二道防线是文件头和文件尾检测。每种备份格式都有固定的文件头标识，比如SQL Server的.bak文件头包含“TAPE“签名，MySQL的.sql文件开头通常是注释行。写个小脚本读取文件前512字节和后512字节，跟标准模板比对，不匹配就报警。这个方法特别适合快速筛查大批量备份文件。
第三道防线是试恢复校验，也叫恢复演练。把备份文件恢复到测试环境，跑几条查询看看数据对不对。这是最彻底的校验方式，也是成本最高的。建议至少每月做一次完整环境的试恢复，每周做一次关键表的抽样校验。
二、文件已经损坏了，还能救吗？
如果校验发现文件确实坏了，别慌。先判断损坏程度。部分损坏的文件往往还能提取出大部分数据。对于数据库备份，可以尝试用工具自带的修复命令，比如SQL Server的RESTORE VERIFYONLY先做只读验证，MySQL可以用mysqlbinlog工具逐条解析binlog。如果文件是压缩格式损坏，试试用7-Zip的“保留损坏文件“选项解压，往往能拿回80%以上的内容。
关键建议：永远不要只保留一份备份。采用3-2-1原则——3份副本、2种介质、1份异地。即便某份文件损坏了，还有其他副本可以兜底。在数据迁移备份场景下，迁移前后都要做完整性校验，迁移过程中用rsync的-c参数做校验传输，这是最省心的方案。