容灾：企业灾备避坑指南

作者：张思远

凌晨三点，那个删库跑路的兄弟哭了

凌晨三点，手机响了。

说实话，干运维这行，最怕半夜来电。屏幕上显示是之前合作过的一个技术负责人老周。接起来，对面声音都是抖的：“兄弟，出大事了，数据库被删了，备份也……也打不开。”

我一下子清醒了。老周那家公司做电商，日活不算大，但一天流水也有大几十万。后来才知道，是他们一个开发在做数据清理时，误连了生产环境，一条不带where条件的delete，把订单表清空了。更致命的是，他们以为每天自动备份就万事大吉，结果备份脚本三个月前就静默失败了，没人发现。

数据丢了整整两天。最后花大价钱找数据恢复公司，也只捞回来一部分。那两天，公司直接损失超过百万，还不算客户流失和口碑。

这事儿之后，我就在想，很多人对“容灾”的理解，真的还停留在“我备份了就行了”的阶段。

容灾到底是个啥？跟备份有啥区别？

一句话解释：备份是防数据丢，容灾是防业务停。

备份解决的是“数据没了怎么办”，容灾解决的是“系统挂了，业务怎么还能跑”。这两件事，一个像给文件存个副本，一个像给整个办公室准备个备用办公地点。

我遇到过不少客户，觉得买了备份一体机就高枕无忧了。结果真出事的时候，发现恢复一个几百G的数据库要六七个小时，业务停摆大半天，损失比数据本身还大。这就是典型的“有备份，没容灾”。

容灾的核心指标就两个：RTO和RPO。

RTO是恢复时间目标，说白了就是“你多久能活过来”。RPO是恢复点目标，意思是“你会丢多少数据”。比如RPO等于15分钟，说明你最多丢15分钟的数据；RTO等于30分钟，说明半小时内业务能恢复。

这两个数，直接决定了你花多少钱、买什么方案。

一个真实的对比场景

去年我跟一个做连锁餐饮的客户聊过。他们有四十多家门店，收银系统跑在本地服务器上。

最开始他们的方案是：每天凌晨备份一次数据库到另一台机器。听起来没问题对吧？但问题在于，如果白天服务器硬盘坏了，从早上十点到第二天凌晨的数据全没了。门店没法收银，只能手写记账，客户体验一塌糊涂。

后来他们调整了方案，做了数据库实时同步加应用层的高可用。主服务器一挂，备用机几十秒内接管，门店端几乎无感知。RPO控制在秒级，RTO不到一分钟。

你看，这就是备份和容灾的区别。前者是“事后补救”，后者是“实时兜底”。

话说回来，也不是所有业务都需要做到这个级别。一个内部OA系统，停两小时可能没人发现；但一个支付网关，停两分钟就是事故。所以容灾方案得看业务到底多“要命”。

两个避坑建议，都是血泪换来的

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

这是我见过最多的坑。很多团队每天看备份日志显示“成功”，就安心了。但备份文件能不能恢复、恢复要多久、恢复出来的数据完不完整，从来没测过。

我自己的做法是：每季度至少做一次恢复演练。随便挑一个备份文件，在隔离环境里真刀真枪恢复一遍，记录耗时、记录问题。有一次我们演练时发现，某个备份文件因为版本不兼容，根本恢复不了。这要是真出事才发现，哭都来不及。

第二个坑：容灾方案没考虑“人”的因素。

技术方案再牛，半夜出事了没人会操作，等于零。我之前用热备云做过异地备份的部署，方案本身挺顺，但后来复盘时发现，值班的同事根本不知道切换流程。真出故障时，还得打电话把已经睡着的DBA叫起来，一来一回半小时没了。

所以后来我坚持一件事：容灾切换流程必须写成“傻瓜文档”，每一步都截图，每个命令都能直接复制粘贴。而且每半年做一次桌面演练，不实际切，但让值班的人对着文档讲一遍。这个习惯，至少帮我避免了两三次半夜的鸡飞狗跳。

说在最后

容灾这件事，说到底不是技术问题，是态度问题。

你愿不愿意花时间去想“如果明天系统全挂了，我怎么办”？你愿不愿意在风平浪静的时候，去折腾那些看起来“没必要”的演练？

我见过太多团队，出事前觉得容灾是成本，出事后才发现那是保费。而且这个保费，往往比损失便宜得多。

如果你们团队现在还没做过恢复演练，我建议这周就安排一次。不用搞多复杂，挑一个不太重要的系统，试着恢复一下。你可能会发现一些平时根本想不到的问题。

至于容灾方案怎么选，是本地高可用还是异地灾备，是数据库层做还是存储层做，这个得看具体业务场景和预算。热备云那边有一套从备份到容灾的完整方案，感兴趣可以去了解一下。但不管选什么，记住一句话：没验证过的容灾，等于没有容灾。

凌晨三点的电话，我希望你永远不用接。