上周和一个做 DBA 的朋友吃饭，他跟我吐槽了一件事：他们公司搞了一次数据库恢复演练，结果发现备份文件里丢了三天的数据。按他的话说，当时会议室里的空气都能拧出水来。这事儿让我想起一个更残酷的事实——很多公司花大价钱买服务器、做冗余，却对恢复策略抱着得过且过的态度。他们以为只要做了备份就万事大吉，但真正到了系统崩盘的那天，才发现自己的恢复方案根本跑不通。数据库恢复策略说白了就是一道防线，既是技术问题，也是对业务连续性负责程度的试金石。
咱们先聊聊最常见的全量备份加增量备份的组合。全量备份就像给数据库拍了张全身照，把所有数据都复制一份；增量备份只记录上次备份后变动的内容，就像只拍那些新增的细节。这个组合的好处是省空间、省时间，但恢复时必须先把全量备份还原，再依次应用增量备份。问题出在哪儿呢？如果增量备份链断了，比如中间某个日志文件损坏，后面的增量备份全都失效。我见过一家电商公司，双十一前一天数据库挂了，他们按这个策略恢复，结果发现第二个增量备份文件是空的，只能恢复到三小时前的状态，丢了几千笔订单。所以，靠谱的做法是定期做全量备份，并把增量备份的完整性检查做成自动化脚本，每天跑一次，别等出事再傻眼。
说到恢复策略，不能不提 RPO 和 RTO 这两个概念。RPO 是你能容忍丢失多少数据，RTO 是你能容忍系统停机多久。很多老板拍脑袋定指标，张口就说“RPO 要零丢失，RTO 要五分钟”，但落地时会发现，要实现这个目标，需要实时同步的灾备系统，成本会翻好几倍。我认识一家金融公司的技术负责人，原本定的是 RPO=0，结果算下来，每年光带宽和硬件就要多花 300 万。后来改成 RPO=15 分钟、RTO=1 小时，采用异步复制加异地备份，成本砍到原来的三分之一。关键是要和业务部门坐下来谈——你们到底能接受丢 15 分钟的数据吗？如果客户下单后 15 分钟内系统崩了，补单流程能否走通？这些细节聊透了，恢复策略才能真正贴合业务需求。
还有一点容易被忽视，那就是恢复策略的验证频率。我观察过不少团队，备份脚本写得漂漂亮亮，却从未真正恢复过。等到灾难降临，才发现恢复步骤里有个路径写死了，或者某个依赖的服务没启动。一个做 SaaS 的朋友曾分享他们的教训：他们每周做一次备份，结果半年后数据库扩容，磁盘分区变了，恢复脚本里的挂载点仍是旧的。恢复那天，脚本跑了一小时报错，手动折腾了六个小时才把数据找回来。现在他们改成每月做一次全量恢复演练，用测试环境模拟真实场景，连业务流量都一起走。演练结束后生成报告，记录恢复耗时和数据一致性检查结果，这些数据反过来推动他们优化备份策略。你看，恢复策略不是写个文档就完事的，它需要一次次实战来打磨。
再聊个更技术的话题——日志备份和数据库恢复的关系。很多人觉得日志备份是凑数，实际上它才是精细恢复的核心。比如凌晨两点发现数据库误删了一张表，如果只有全量备份，你只能恢复到凌晨两点的全量备份，然后重放所有日志到误删前的时刻。但如果日志备份做得不好，比如归档日志没开启，或者日志文件被循环覆盖，那只能恢复到最近的整点备份，期间的数据全丢。我见过一个医疗系统的案例，他们因为日志文件空间不足，自动删除了三小时的归档日志，结果只能回到四小时前的状态，丢失了急诊记录，随后被卫健委通报批评。所以，日志备份策略必须和备份窗口、磁盘空间、恢复粒度一起规划，别等出事了才意识到日志和命一样重要。
说到恢复策略的自动化，这里坑更多。很多团队用 cron job 跑备份脚本，觉得万事大吉。但自动化不等于可靠，你得考虑网络抖动、磁盘写满、权限变更等问题。我有个做游戏运维的朋友，他们用自动化脚本每晚做备份，结果有个月磁盘报警一直没处理，备份任务连续失败了七天，自己也没发现。等游戏宕机需要恢复时，才发现最近一次成功的备份是八天前的。这事儿后来成了他们部门的笑话。现在他们给备份任务加了监控和告警，失败后自动重试，重试三次仍失败就发短信给值班人员。恢复策略的自动化核心是“可见性”——你必须能看到备份状态、恢复耗时、数据完整性，而不是把任务交给脚本后不管。好的自动化让你睡得安稳，而不是蒙着眼走钢丝。
那怎么判断一个恢复策略好不好呢？我的经验是看三个维度：备份覆盖率、恢复速度、数据一致性。备份覆盖率要覆盖所有业务数据库，包括那些看似不重要但实际在用的小库。恢复速度要量化，比如全量恢复加日志应用的总时长，必须知道极限情况下的最坏时间。数据一致性最难搞，尤其是跨库事务的场景。我见过一个电商平台，订单库和库存库分别备份，恢复后发现订单库恢复到 10 点，库存库恢复到 9 点 50 分，导致订单与库存不匹配。后来他们引入全局时间戳和分布式事务日志，才解决了这个问题。判断恢复策略好坏，不是看文档有多厚，而是看真正出事后，业务能否在三小时内重新跑起来，数据能否实现分钟级恢复。
想说一句，数据库恢复策略不是技术部门的事，它是整个公司的命根子。我见过太多公司，平时觉得备份就是 DBA 的分内事，老板不关注，业务部门不参与。等到系统崩了，老板才急得跳脚，业务部门才抱怨数据丢得太狠。其实恢复策略应该像消防演练一样，定期拉出来演练。可以从一个小项目开始，比如选一个非核心业务数据库，做一次完整的备份恢复演练，记录所有问题点。然后逐步扩展到核心系统，让业务部门参与验证恢复后的数据是否正确。这个过程会暴露很多隐患——比如权限问题、网络带宽瓶颈、存储性能不足。每解决一个，你的恢复能力就提升一分。记住，恢复策略是动态的，需要随业务发展和技术迭代一起进化。别等灾难来临那天，才后悔当初没把这事儿搞扎实。
