4. 灾难恢复策略制定：选择恢复方案（热站、冷站、温站）
你问我灾备方案里最重要的一步是什么？
就是选一个合适的恢复站点。站点选错，后面的演练全是白忙活。
我见过不少团队，花大价钱买了全套热站设备，结果业务量根本用不上；也有人为了省钱选冷站，真出事后恢复花了两周，客户全跑了。嗯，这个平衡点不好找。
三种站点的核心差异
说白了，热站、温站、冷站的区别就三个维度：数据延迟、恢复时间、成本。
我习惯用一张表格先理清楚它们的长短：
| 站点类型 | 数据同步方式 | 典型 RPO | 典型 RTO | 相对成本 | 典型场景 |
|---|---|---|---|---|---|
| 热站 | 实时同步 / 异步复制 | 秒级～分钟级 | 分钟级～1小时 | 极高（≈主站 80～100%） | 金融交易、在线支付、核心交易系统 |
| 温站 | 定时同步（小时/天） | 小时级～天级 | 数小时～1天 | 中等（≈主站 30～50%） | ERP、CRM、中等规模电商 |
| 冷站 | 定期备份（磁带/离线介质） | 天级～周级 | 数天～数周 | 低（≈主站 5～15%） | 归档、日志存储、非关键系统 |
关键指标
- RPO（恢复点目标）：你最多能容忍丢多少数据？
- RTO（恢复时间目标）：你最多能接受系统中断多久？
- 成本与可用性永远是对手——没有免费的灾备。
热站：贵，但真的快
热站就是一份实时的全量副本。主站点跑什么，热站就同步什么。我记得在之前一个银行项目里，客户要求 RPO 不超过 5 秒，RTO 控制在 10 分钟以内。这怎么办？只能上热站。
我们用了同步复制 + 跨城光缆，核心账务系统两边同时写。平时还要定期切流量验证，不然你真不知道备机能不能撑住。有一次演练，刚切过去发现数据库有死锁——嗯，那是另一个故事了。
实战小贴士
热站不要只关注数据同步。应用程序的配置、负载均衡策略、网络路由这些也要一起同步。我曾经遇到过站点切换后，业务能连上但 API 网关证书过期了——这种坑最冤。
温站：折中的艺术
温站算是我最常推荐的方案。不上不下的企业，预算有限但又不能接受几天恢复的，温站最合适。
数据同步频率一般设到小时级。比如每4小时从主站增量备份一次，网络带宽够的话也可以用异步复制，稍微拉近RPO。
温站的基础设施是半就绪的：服务器、存储、网络都通电，但数据库空着，应用没部署。等灾难来了，你要手动部署应用、恢复数据、启动服务。
我在一个电商公司做过温站方案，他们平时峰值流量只有几百QPS，但双11能冲到几万。温站平时跑低配，双11前两周切到主站扩容，灾备那边临时升级，算下来省了40%的硬件成本。
冷站：只适合能等的业务
冷站就是一间空机房，电源、空调、机柜装好，其他什么都没有。数据靠磁带或者离线硬盘送过去。恢复的时候要先上架设备、装系统、恢复备份……周而复始。
说实话，冷站现在应用场景越来越窄。云原生时代，很多企业直接上云做灾备了。但如果你做的是合规要求极高的金融归档，或者政府部门的历史数据保留，冷站还是有一席之地的。
避坑指南
我经常提醒团队：冷站不等于“什么都能恢复”。曾经有个项目，他们把备份磁带送到冷站，结果磁带机型号不匹配，读不出来。后来我要求冷站里必须保留至少两代不同接口的磁带机，加上验证脚本。
怎么选？画个决策树
你可能想问：我到底该选哪种？这没有标准答案。我一般让团队先回答三个问题：
- 业务能停多长时间？（对应RTO）
- 最多能丢多少数据？（对应RPO）
- 预算能覆盖主站成本的百分之几？
拿这三个值去套上面的表格，基本八九不离十。
下面这张图是我个人习惯用的决策流程，帮你快速缩小选项：
别忘了这个关键点
不管选了哪种站，定期演练才是保命符。我见过某大型企业，温站建了三年没切过，真出事了发现网络不通、应用版本不匹配、数据库密码过期——全废了。
我建议至少每季度做一次桌面推演，每半年做一次实际切换演练。演练过程要记录时间戳，和RTO对标。如果连续三次都能达标，那你的方案才算是“活着”的。
我的习惯
选型的时候，我还会额外考虑一个变量：运维团队的能力。冷站对运维要求低，但热站需要7x24小时值班、熟悉同步和切换脚本的专家。如果团队只有两三个人，选热站就是给自己埋雷。
好了，关于三种站点的差异和选择策略，就聊到这里。你下次做灾备方案时，多想想RPO和RTO这对冤家，再回来翻翻这张决策图，心里就有底了。