去年冬天，凌晨两点，一个客户打电话过来，声音发抖：“我们数据库崩了，快帮我恢复一下。”

我问他：“备份有吗？”

“有！每天自动备份，从来没断过。”

“那你恢复一下试试？”

二十分钟后，他回电话：“恢复不了。备份文件是坏的，从三个月前就开始坏了。”

那天晚上，他们团队手工从binlog里捞数据，折腾到天亮，最后丢了将近一天的用户订单。第二天复盘，发现一个扎心的事实：备份跑了三年，一次都没恢复过。

这不是个例。我见过太多公司，备份脚本写得漂亮，监控也配了，但从来没真正验证过备份能不能用。直到出事那天，才发现“保险”早就不保了。

今天聊聊云上灾难恢复演练。不是那种“备份很重要”的废话，而是帮你理清楚：怎么练、练什么、多久练一次，才能确保真出事的时候不慌。

01 备份不是目的，恢复才是

这句话值得刻在每台数据库服务器上。

很多人以为买了云厂商的备份服务就万事大吉了。RDS开了自动备份、S3开了版本控制、虚拟机做了快照——安全了，可以睡觉了。

但备份只是过程。恢复才是目的。一个从没恢复过的备份，和没有备份没有区别。

我做过一个小调查，问了几十个运维朋友：“你们最近一次成功恢复备份是什么时候？”答案让人后背发凉：超过60%的人回答“没恢复过”或“不记得了”。 更可怕的是，有几个人说“上次恢复是三年前，当时成功的，现在不知道还行不行”。

这就是灾备演练的意义——确认你的“保险”真的能赔。

02 不演练，你永远不知道会踩什么坑

我整理了几个真实踩过的坑，每一个都是“以为有备份，结果恢复不了”。

坑一：备份文件损坏

最常见的坑。备份脚本一直跑，但从来没检查过文件完整性。RDS自动备份有校验，但如果你自己用mysqldump跑脚本，没人帮你检查。日志显示“备份成功”，但文件是坏的。

坑二：恢复时间远超预期

有个客户，业务数据几个TB，平时备份到Glacier。真出事那天，从Glacier取回数据花了12小时，恢复又花了8小时，业务挂了整整一天。他们一直以为“恢复几个小时就够了”，从来没测过。

坑三：权限不够

更离谱的：备份文件存在S3上，加了权限控制。但负责恢复的人离职了，权限没移交。新来的工程师发现，他根本读不了那些备份文件。重建权限又花了半天。

坑四：文档过期

演练文档是三年前写的，里面写的服务器IP、账号密码、命令路径，全都变了。真恢复的时候，拿着旧文档干瞪眼。

这些坑，只要跑一次演练就能发现。但没人跑，坑就一直在那，等着出事那天。

03 演练到底练什么？

灾备演练不是“把备份文件拷出来看看”。要练的东西分三层。

第一层：技术恢复

• 数据能不能成功恢复？恢复到指定时间点？

• 恢复出来之后，数据完整吗？能正常访问吗？

• 恢复花了多长时间？有没有超出RTO（恢复时间目标）？

这一层是最基本的。数据库、虚拟机、对象存储，每一种数据源都要验证。

第二层：业务验证

数据恢复出来，不等于业务能跑。

• 应用能连上恢复后的数据库吗？

• 配置要改吗？IP变了怎么办？

• 依赖的服务都起来了吗？

我见过一个案例，数据库恢复了，但应用连的还是老IP，改了配置才通。这一改，又花了半小时。如果提前演练过，这个坑就能填上。

第三层：流程和人员

• 恢复流程文档还准吗？

• 该有权限的人还有吗？

• 大家知道出事第一步该找谁吗？

这一层最容易忽略，也最容易出事。

04 多久练一次？怎么练？

演练频率没有标准答案，但有几个参考原则。

• 关键业务：每季度一次。核心交易系统、支付系统，出事影响太大，必须高频验证。

• 一般业务：每半年或每年一次。普通应用、内部系统，频率可以低一些。

• 合规要求：按行业规定。金融、医疗等监管行业可能有强制要求。

怎么练？不用每次都搞“全真模拟”那么大动静。

小演练：只验证数据恢复。挑一个非核心的备份文件，恢复到测试环境，看看数据对不对。一个小时搞定。

中演练：验证恢复+业务验证。选一个业务低峰期，在测试环境完整恢复一套系统，验证应用能否正常跑。半天时间。

大演练：真实切换。把生产流量切到恢复出来的系统上，验证灾备环境真正能撑住。一年一次就够，选个周末。

从小的开始，先跑通最简单的场景，再慢慢增加难度。

05 演练完了，然后呢？

演练不是跑完就完了。要记录、复盘、改进。

• 记录：这次演练花了多长时间？卡在哪一步？数据丢了没？

• 复盘：流程哪里不顺？文档哪里不对？权限哪里不够？

• 改进：优化流程、更新文档、调整备份策略。

有一个客户，第一次演练发现恢复需要6小时，远超RTO目标。复盘后改了恢复脚本、优化了数据架构。第二次演练只用了1.5小时。

灾难恢复能力不是买出来的，是练出来的。

06 一个真实案例

去年帮一个电商公司做灾备演练。他们一直觉得自己“有备份就安全”，但从来没跑过。

第一次演练，我们选了一个非核心的MySQL从库，从RDS自动备份里恢复。结果：

• 备份文件是好的，但恢复到一半，磁盘空间不够——没人算过恢复需要的空间。

• 重新分配磁盘后，恢复成功，但应用连不上——IP变了，配置没改。

• 改了配置，应用能连了，但数据少了最后15分钟——他们用的是每天一次备份，恢复点是凌晨2点，数据丢失了十几个小时。

整个过程折腾了4个小时。

复盘后，他们改了策略：核心库开实时备份（PITR），恢复演练脚本化，恢复流程文档重写。

三个月后第二次演练，从头到尾只用了40分钟。运维负责人说：“现在晚上敢关机睡觉了。”

写在最后

那个凌晨打电话的客户，后来花了三个月重建了备份体系和演练流程。现在每季度跑一次演练，每次跑完都写复盘报告。今年问他，他说：“最近一次演练，从备份到业务恢复，25分钟。”

我说：“如果去年出事前你们就跑过演练……”

他打断我：“别说了，那天的损失够我们演练一百年了。”

备份这件事，平时看不见，出事才要命。但真到那时候，没人给你第二次机会。

你的备份，上次恢复是什么时候？今天就可以试试。挑一个非核心的系统，跑一次恢复演练。用不了半天，但能让你今晚睡踏实点。

毕竟，数据丢了，才知道有多疼。