灾难恢复架构图：RPO、RTO 与四种策略

高可用让系统在某台服务器或某个可用区故障时继续运行。灾难恢复针对的是更大的故障：整个区域宕机、数据库损坏、账号被删除、勒索软件。应对这些情况的计划必须在事情发生之前就准备好，而你会丢失多少数据、停机多久，是由架构决定的。

本文先定义每个灾难恢复（DR）设计都要从中出发的两个数字，再逐一介绍四种标准策略及其成本，最后画出一个跨两个区域的温备方案。

RPO 与 RTO

• 恢复点目标（RPO）： 你能承受丢失多少数据，以时间来衡量。RPO 为 5 分钟，意味着丢失最近 5 分钟的写入是可以接受的。
• 恢复时间目标（RTO）： 服务在恢复之前可以停机多久。

这两个数字都来自业务，而不是工程，而且都要花钱：每向零数据丢失、零停机迈进一步，基础设施和运维工作量都会成倍增加。问清楚停机一小时的代价是多少、哪些数据无法重建，然后选择满足这些数字的最便宜的设计。同一个系统的不同部分通常有不同的目标：结账可能需要在几分钟内恢复，报表数据仓库则可以等一天。

四种策略

AWS 灾难恢复白皮书 按成本和恢复速度把 DR 分为四种策略。同样的思路适用于任何云平台，也适用于你自己的数据中心。

备份与还原 从备份和基础设施代码重建一切。只要还原流程经过测试、基础设施能从代码重新创建，这对许多内部系统来说就足够了。

指示灯 让数据保持在线（复制的数据库、复制的存储桶），但计算资源关闭或缩到零。恢复意味着启动服务并扩容。

温备 让一个规模较小但能正常工作的副本持续运行。它可以立即以较低容量承载流量，并在故障转移期间扩容。由于它一直在运行，测试起来也很容易。

双活 始终同时从两个站点为用户提供服务。故障转移基本上只是一次路由变更，但在两个区域写入会带来冲突处理问题，或者需要单写入方的设计，成本则是两套生产环境。

为一个系统做选择：示例

一家每小时接收 2,000 笔订单的网店，要求结账的 RPO 为 5 分钟、RTO 为 30 分钟。备份与还原达不到 RPO：每晚一次的快照可能丢失一整天的订单，而重建整套系统需要数小时。指示灯通过数据库复制可以满足 RPO，但在另一个区域启动并预热服务、缓存和搜索索引，第一次尝试时通常要超过 30 分钟。温备两者都能满足：副本只落后几秒，缩小规模的服务也已经在运行，所以故障转移只需要提升副本、扩容和切换 DNS。双活能把 RTO 进一步缩短，但成本翻倍，还会带来这家网店根本不需要解决的写入冲突。结论是：结账用温备，报表数据仓库用备份与还原。

备份依然必不可少

复制同样会复制错误。如果有人删了一张表，或者勒索软件加密了数据，副本几秒内就会跟着变。要保留复制无法触及的时间点备份：

• 保留数天或数周的快照和事务日志。
• 放在另一个账号中、使用不同凭据的副本，这样一个账号被攻破时无法把两者都删掉。
• 平台支持的话，使用不可变或锁定的备份。
• 定期做还原测试。从没有人还原过的备份只是一种希望，算不上备份。

故障转移的步骤

把步骤写下来，并保持简短：

1. 做出决定。 谁有权宣布灾难，依据什么信号。整个区域的自动故障转移风险很大；许多团队把检测自动化，但把决定权留给人。
2. 提升数据库副本。 把备用区域的副本提升为主库。
3. 扩容计算资源。 把备用区域扩容到满容量。
4. 切换流量。 修改 DNS 故障转移记录或全局负载均衡器的权重。要考虑 DNS 的 TTL 以及会缓存结果的客户端。
5. 验证。 用合成监控检查，然后对外公告。
6. 规划回切。 切回原站点是第二次迁移，需要同样的谨慎。

架构图

这张图的读法如下：

• 顶部： 用户到达 DNS 故障转移路由。目前它把全部流量发往主区域；虚线连线表示故障转移后流量的去向。
• 左侧，主区域： 一个负载均衡器、六个应用实例、对象存储和主数据库。
• 右侧，备用区域： 同样的结构，但规模更小：两个应用实例、一个通过异步复制更新的副本数据库，以及复制过来的对象。虚线连线标出了只在故障转移后才承载流量的路径。
• 底部： 每天的快照存入另一个账号中的备份保管库，提供复制无法提供的、针对数据损坏和删除的保护。
• Markdown 块 写明了这个设计要达到的目标。

测试

DR 计划往往败在细节上：备用区域里过期的证书、写死的端点、缺失的密钥、长达一天的 DNS TTL。唯一的办法是真正执行一次故障转移。安排演练，从单个服务开始，把实际的 RTO 与目标对比。温备让这件事成本很低，这也是它相对指示灯最大的优势之一。

DR 架构图上应该画什么

• 两个站点， 以及各自运行什么、运行规模多大。
• 复制路径及其模式， 同步还是异步，因为这决定了 RPO。
• 流量切换开关， 以及它是否自动。
• 影响范围之外的备份， 包括账号边界。
• 目标， 直接写在设计旁边。

多区域的网络部分，请参见 AWS 多区域架构图。数据库复制图 更深入地解释了复制延迟和故障转移，事件响应流程图 则介绍了如何宣布和处理事件本身。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图。
2. 添加云节点包中的两个 区域 框架，一个表示主区域，一个表示备用区域。
3. 在每个区域中添加一个 云负载均衡器、一个表示应用的 计算实例 节点、一个 对象存储 节点和一个 托管数据库。把实例数量写在标签里。
4. 在区域上方添加 C4 模型节点包中的一个 人员 和网络节点包中的一个 DNS 节点，在下方再添加一个 对象存储 节点作为备份保管库。
5. 画出跨区域的复制，把只在故障转移时使用的路径画成虚线，再添加一个基础节点包中的 Markdown 块，写明 RPO 和 RTO。

这个示例共用 14 个图表节点，在 Free 套餐的限制之内。

常见问题

RPO 和 RTO 有什么区别？ RPO 是你能丢失多少数据，以故障发生前的时间来衡量。RTO 是故障发生后恢复服务需要多长时间。

高可用和灾难恢复是一回事吗？ 不是。高可用自动且持续地处理组件和可用区的故障。灾难恢复处理更大的事件，比如整个区域宕机或数据损坏，通常需要一次有意识的故障转移。

如果已经复制到另一个区域，还需要备份吗？ 需要。复制几乎会立即把删除和损坏也复制过去。放在另一个账号中的备份可以防范这些情况。

应该选择哪种灾难恢复策略？ 选择能满足业务对该系统所需 RPO 和 RTO 的最便宜的那种。温备是常见的折中方案，因为它价格适中，也便于测试。

灾难恢复应该多久测试一次？ 频率要足以让运行手册保持准确，对关键系统通常是每季度一次，并且在每次重大架构变更之后都要测试。

免费开始 — 1 个席位，无需信用卡。