灾备：企业灾备避坑指南

作者：赵启明

昨天半夜，老王给我打电话，声音都是抖的。

他是一家连锁餐饮企业的IT负责人，系统在晚上十一点突然宕机了。收银系统、会员系统、库存系统全瘫，所有门店的订单只能手写。更要命的是，数据库文件损坏，最近一周的营业数据基本没救回来。第二天早上，老板在办公室拍了桌子，财务在群里发了三遍"损失统计表"，他一个人在机房坐到天亮。

老王问我："你说我当初要是做了灾备，是不是就不会这样了？"

我不知道怎么接话。

灾备到底是个啥？

说白了，灾备就是"预防数据末日"的保险。

数据这东西，平时看不见摸不着，但一旦丢了，就是真金白银的损失。灾备干的事，就是在你的生产系统之外，再准备一份或多份"可用的备份"，确保万一主系统出事，你能快速恢复，业务不至于中断太久。

但说实话，很多人对灾备的理解是错的。我之前接触过一个客户，以为买了块移动硬盘，每周手动拷贝一次数据就算灾备了。直到有一天，机房进水，硬盘泡了，他才知道什么叫"欲哭无泪"。

灾备不是"备份"两个字那么简单。它至少包含两层意思：一是数据备份，二是业务接管。数据备份好理解，就是定期把数据复制一份；业务接管则是说，当原系统不可用时，备用的系统能不能顶上去，让业务继续跑。

打个比方。备份是给房子上了把锁，灾备是房子被烧了之后，你还能住进隔壁一模一样的房子。锁再结实，也挡不住火灾。你真正需要的，是"备用房"。

什么情况下你会用到灾备？

很多人觉得灾备是银行、政府、大企业才需要的东西。我遇到过一个做电商的客户，年营收两三千万，他觉得自己的体量"不配"搞灾备。结果赶上一次云服务商机房故障，他的店铺整整停了四天。四天啊，双十一的流量全便宜了竞争对手。后来他算了一笔账，那次的损失，够他买十年灾备服务。

我遇到过的事故类型，五花八门：

勒索病毒加密整个服务器，不交比特币就撕票（真实案例，最后数据全没了）；

机房空调坏了，温度过高，硬盘集体罢工；

运维手滑误删了生产数据库（这个太多了，我都不想举例）；

自然灾害导致机房断电断网（有客户在郑州，720那事大家应该有印象）。

你说这些事概率低不低？确实低。但一旦发生，对一个企业来说，就是百分之百的灭顶之灾。而且，没有灾备的话，你连"止损"的选项都没有。

我踩过的坑，说给你听

做这行年头多了，我自己也犯过不少错。有几个坑，是真的拿教训换来的。

第一个坑：备份了，但没验证过能不能恢复。

早年间我给一家制造企业做方案，每周都自动备份，日志看着都正常。直到一次事故需要恢复，才发现备份文件早就损坏了。原因很简单——备份软件版本更新后，备份格式变了，旧的恢复工具不兼容。这事儿后来花了两天时间才解决，客户差点起诉我。

从那以后，我养成了一个习惯：每季度至少做一次恢复演练。别嫌麻烦，备份不是"做出来"就行，必须"能恢复"才算数。恢复不了，你备份了个寂寞。

第二个坑：灾备中心选得太远或太近。

有个客户，灾备中心就建在隔壁机房，共享同一路电力。结果一次区域性断电，两个机房一起黑。后来我把灾备中心挪到了另一个城市的云平台上，才算安心。但也不能太远——主备之间如果跨大区域，数据同步的延迟会很高，实时性要求高的业务根本扛不住。

第三个坑：只做了数据备份，没做业务接管。

数据是恢复了，但系统起不来，照样干瞪眼。灾备的终极目标是"业务连续性"——用户访问你的系统，感觉不到任何异常。这一点，很多企业都没做到。数据备份只是"保底"，业务接管才是"翻盘"。

给你两个实在的建议

说实话，灾备这事儿，方案千千万，但核心就两点：架构要简单，流程要跑通。

第一，"两地三中心"是最稳的底子。什么意思？本地机房一份数据，同城另一个机房一份，异地再放一份。听起来复杂，但现在的方案商都能帮你搞定。我有个客户，用了中科热备的方案，主备切换能做到分钟级，数据丢失控制在秒级以内，成本远比想象中低。不过，这里面有个前提——你得知道自己能承受多少数据丢失（RPO）和多少停机时间（RTO），这两个指标定下来，方案才有意义。

第二，别信"上了系统就万事大吉"。灾备是一个持续运营的过程，不是一次性采购。人员变动、系统升级、业务扩展，都会影响灾备的有效性。我见过太多企业，第一年认真做灾备，第二年敷衍，第三年直接不做了。结果第四年出事，前三年全白干。

最后说一句掏心窝子的话：灾备这件事，做的时候永远觉得"没必要"，出事的时候永远觉得"怎么没早做"。我没法替你做决定，但如果你还在犹豫，不妨先问问自己——你愿意拿公司的全部数据，赌一把明天不会出事吗？

反正老王现在不赌了。他说，那晚之后，他在机房里坐了一整夜，第二天就去找供应商谈方案了。