文 | 少个分号 （转载请注明出处）
公众号：TechLead 少个分号
知乎：少个分号
微信号：shaogefenhao
网站：shaogefenhao.com
01 基础知识
什么是灾难恢复？
灾难恢复（Disaster Recovery，DR）是指在灾难发生时，组织或系统能够快速恢复业务连续性和服务的能力。
一般信息系统发展到一定的规模，都会考虑做灾难恢复方案。
PS：本文讨论的是业务系统，不是基础设施，总结业界实际做法，而非教科书上的规范操作。
什么是 RTO/RPO？
RTO/RPO 是衡量灾难恢复的两个指标，一般是需要先定这两个指标然后在选择合适的策略。
-
RTO（Recovery Time Objective）：恢复时间目标，指系统从灾难恢复到业务连续性恢复的时间目标。 -
RPO（Recovery Point Objective）：恢复点目标，指系统在灾难发生时，允许丢失的最大数据量。
常见的定义级别有：
-
分钟级（Minute级）：RTO 为 1 分钟，RPO 为 1 分钟内的数据丢失。 -
小时级（Hour级）：RTO 为 1 小时，RPO 为 1 小时内的数据丢失。 -
天级（Day级）：RTO 为 1 天，RPO 为 1 天内的数据丢失。
我们通过 RTO/RPO 的级别（可以让业务来定）选择合适的灾难恢复模式。
02 常见的几种灾难恢复模式
数据备份恢复（Backup & Restore）
这里的备份是指数据备份，不是系统冗余。定期数据备份，灾难后手动恢复。
手动恢复的意思是重新买服务器整个重新配置一遍，对于一些大的系统来说要搞几个小时到几天。
-
RTO（恢复时间目标）：小时～天级 -
RPO（恢复点目标）：上次备份时间点，取决于备份频率 -
成本：最低 -
优点：简单、便宜 -
缺点：恢复时间长、数据可能丢失 -
适用场景：数据不常变动、对可用性要求不高的小系统
冷备（Cold Standby）
这里的备是指准备，不是备份，类似汽车的备胎。灾难发生后启动备用系统，日常系统不开机。
-
备用环境闲置，未运行 -
手动切换，数据同步频率较低（如每日） -
RTO：数小时～天级 -
RPO：较高 -
成本：低 -
适用场景：预算有限、可接受较长恢复时间的业务
热备（Hot Standby）/ 热灾备
主从部署，实时或近实时同步。
-
从系统常驻运行，但不承担业务负载 -
手动/自动切换 -
RTO：分钟～小时级 -
RPO：接近实时 -
成本：中等 -
适用场景：中等业务连续性要求的关键服务，如数据库灾备。
对于业务系统来说非常鸡肋，一般都不会用这种模式，如果要做热灾备，一般都是直接用同城多活或者异地多活。
同城双活（Active-Active in One City）
两个数据中心在同城同时对外服务，需要修改代码实现。
-
负载均衡共同承担流量 -
实时数据同步（强一致或最终一致） -
RTO：秒～分钟级 -
RPO：0（一般是同步写） -
成本：高 -
挑战：需要精细的容灾切换、数据冲突处理 -
适用场景：金融、电商、政务系统等关键系统
一般基础设施用的比较多，如果上同城双活的话，一般都是同城多活，异地多活。
异地多活（Geo-Active-Active / 多地多活）
多个地理位置数据中心同时对外服务，才能真正解决灾难的场景。
-
既然花了钱，往往一般都直接做异地多活。 -
实现 业务级多活（如用户按地域路由） -
通常采用最终一致性模型（CAP 选择了AP） -
RTO：基本为 0（无感知切换） -
RPO：几乎为 0 -
成本：极高 -
技术复杂度高：跨地域网络、事务冲突、分布式系统设计 -
适用场景：阿里、腾讯、AWS 等超大规模业务
04 如何选择这几种模式？
选择这几种模式可以通过：业务重要性、RTO/RPO 级别、成本预算来确定。
根据经验，核心业务一般可以使用热备份。
RTO/RPO 在秒级别一般要做双活或者多活才能实现；如果在小时级温备份就可以了，如果是天级别冷备份即可。
除非重要的业务，一般不做双活或者多活，需要修改数据同步策略，对程序侵入比较高。
业界比较常规的做法是普通系统只做备份和恢复，甚至很多系统恢复演练都没做，导致灾难发生时花很长时间才能重新搭建系统。
一般企业高性价比的策略是对数据库做热备份、对业务系统做冷备份（保证不丢数据，系统能快速启动起来）。
真正需要做灾难恢复的系统，往往直接做异地多活，同城多活的性价比不高。
因为做多活需要考虑数据同步、容灾切换等问题，成本也比较高，同时实现了数据分区同步，就能实现不同城市的横向拓展。
05 其它注意事项
灾难恢复（DR）方案包含哪些东西？
一套 DR 方案一般包含：
-
RTO/RPO 定义：业务影响分析 -
灾难等级划分：定义不同级别的灾难场景 -
恢复策略设计：参考上面内容定义如何设计恢复策略 -
监控与故障检测机制：如何判定和监控故障发生 -
灾难恢复流程（DR Runbook）触发条件：责任人名单，具体操作指令（数据库、应用、缓存、DNS、切换流量方案） -
系统依赖的组件清单：包括基础设施和上下游集成系统
灾难恢复演练（DR Drill）
定期进行演练（每季度/半年）。
模拟真实故障：断链路、杀节点、网络分区，验证切换流程、数据一致性、业务稳定性。
不演练的 DR 方案等于无效！
06 参考资料
-
AWS Disaster Recovery -
Azure Business Continuity and Disaster Recovery -
Google Cloud Disaster Recovery Planning Guide
作者出品
往期精选 MORE
系统设计 ｜ 一文了解现代广告系统的逻辑
系统设计 | 何同学翻车，开源 License 该怎么管理？
系统设计 | AI 友好的系统设计经验（Cursor 使用体验）