# REL 13 如何规划灾难恢复 (DR)？
拥有适当的备份和冗余工作负载组件是您的 DR 策略的开始。[RTO 和 RPO 是您恢复工作负载的](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 目标。根据业务需求设置这些目标。通过实施策略来实现这些目标，同时考虑工作负载资源和数据的位置和功能。中断概率和恢复成本也是关键因素，有助于了解为工作负载提供灾难恢复的商业价值。
**Topics**
+ [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 测试灾难恢复实施以验证实施效果](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 管理 DR 站点或区域的配置偏差](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 自动执行恢复](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 定义停机和数据丢失的恢复目标
工作负载具有恢复时间目标（RTO）和恢复点目标（RPO）。
*恢复时间目标 (RTO)* 是指服务中断和服务恢复之间的最大可接受延迟。这可以确定在服务不可用时被视为可接受的时间窗口。
*恢复点目标 (RPO)* 是指自上一个数据恢复点以来的最大可接受时间。这可以确定在上一个恢复点和服务中断之间可接受的数据丢失程度。
在为您的工作负载选择合适的灾难恢复（DR，Disaster Recovery）策略时，RTO 和 RPO 值是重要的考虑因素。这些目标由业务部门确定，然后由技术团队用来选择和实施 DR 策略。
**期望结果：**
每个工作负载都有一个根据业务影响定义的指定 RTO 和 RPO。工作负载被分配到一个预定义的层，该层定义服务可用性和可接受的数据丢失，以及关联的 RTO 和 RPO。如果无法进行这样的分层，那么可以为每个工作负载分配定制的分层，用于以后创建层。在为工作负载选择灾难恢复策略实施时，使用 RTO 和 RPO 作为主要考虑因素之一。在选择 DR 策略时还要考虑成本约束、工作负载依赖关系和运维需求。
对于 RTO，了解基于中断持续时间的影响。是线性的还是非线性的影响？（例如，四小时后，您关闭一条生产线，直到下一班开始）。
如下所示的灾难恢复矩阵可以帮助您了解工作负载的重要性与恢复目标之间的关系。（请注意，X 轴和 Y 轴的实际值应根据您组织的需求进行定制）。
![\[显示灾难恢复矩阵的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**常见反模式：**
+ 未定义恢复目标。
+ 选择任意恢复目标。
+ 选择过于宽松并且不符合业务目标的恢复目标。
+ 不了解停机和数据丢失的影响。
+ 选择不切实际的恢复目标，如零恢复时间和零数据丢失，这对于您的工作负载配置可能无法实现。
+ 选择比实际业务目标更严格的恢复目标。这将强制实施比工作负载所需的成本更高并且更复杂的 DR。
+ 选择与所依赖工作负载的恢复目标不兼容的恢复目标。
+ 您的恢复目标没有考虑法规合规性要求。
+ 为工作负载定义了 RTO 和 RPO，但从未测试过。
**建立此最佳实践的好处：** 在指导您的 DR 实施时，需要您的恢复时间目标和数据丢失恢复目标。
**未建立此最佳实践暴露的风险等级：** 高
## 实施指导
对于给定的工作负载，您必须了解停机和数据丢失对业务的影响。随着停机时间或数据丢失的增加，影响通常会越来越大，但这种增长的形式可能会因工作负载类型而异。例如，您也许可以容忍长达一小时的停机时间而没有多大影响，但在一小时之后影响会迅速上升。对业务的影响表现为多种形式，包括货币成本（如收入损失）、客户信任（以及对声誉的影响）、运维问题（如错过工资发放或生产力下降）和监管风险。使用以下步骤了解这些影响，并为您的工作负载设置 RTO 和 RPO。
**实施步骤**
1. 确定此工作负载的业务利益相关者，并与他们一起实施这些步骤。工作负载的恢复目标是一项业务决策。然后，技术团队与业务利益相关者合作，使用这些目标来选择 DR 策略。
**注意**
对于步骤 2 和 3，您可以使用 [实施工作表](#implementation-worksheet).
1. 通过回答以下问题，收集必要的信息来做出决策。
1. 在组织中，您是否对工作负载影响的重要性进行了分类或分级？
1. 如果有，请将此工作负载分配到一个类别
1. 如果没有，则建立这些类别。创建不超过五个类别，并细化每个类别的恢复时间目标范围。类别示例包括：关键、高、中、低。要了解工作负载如何映射到类别，请考虑工作负载是任务关键型、业务重要型还是非业务驱动型。
1. 根据类别设置工作负载 RTO 和 RPO。始终选择比进入此步骤时计算的原始值更严格的类别（更低的 RTO 和 RPO）。如果这导致值发生了不适当的较大改变，那么考虑创建一个新类别。
1. 根据这些答案，为工作负载分配 RTO 和 RPO 值。这可以直接完成，也可以通过将工作负载分配给预定义的服务层来完成。
1. 在工作负载团队和利益相关者可访问的位置，记录此工作负载的灾难恢复计划（DRP，disaster recovery plan），此计划是组织的 [业务连续性计划（BCP，Business Continuity Plan）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)的一部分
1. 记录 RTO 和 RPO，以及用于确定这些值的信息。包括用于评估工作负载对业务影响的策略
1. 除 RTO 和 RPO 之外，记录您根据灾难恢复目标正在跟踪或计划跟踪的其他指标
1. 在进行创建时，您将 DR 策略和运行手册的详细信息添加到此计划中。
1. 通过在如图 15 所示的矩阵中查找工作负载的重要性，您可以开始建立为组织定义的预定义服务层。
1. 根据 实施 DR 策略（或 DR 策略的概念验证）之后，[REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md)测试此策略以确定工作负载的实际 RTC（Recovery Time Capability，恢复时间能力）和 RPC（Recovery Point Capability，恢复点能力）。如果这些能力没有达到所预期的恢复目标，那么，要么与您的业务利益相关者一起调整这些目标，要么对 DR 策略进行更改以便实现预期的目标。
**主要问题**
1. 在对业务产生严重影响之前，工作负载可以停止的最长时间是多少
1. 确定在工作负载中断时，每分钟业务的货币成本（直接财务影响）。
1. 请注意，影响并不总是线性的。影响可能在一开始是有限的，然后在超过一个关键时间点后迅速增加。
1. 在对业务造成严重影响之前，可以丢失的最大数据量是多少
1. 对于最关键的数据存储，请考虑此值。确定其他数据存储的各自关键性。
1. 如果工作负载数据丢失，是否可以重新创建？ 如果这在操作上比备份和还原更容易，那么根据用于重新创建工作负载数据的源数据的重要性来选择 RPO。
1. 此工作负载所依赖的工作负载（下游）或依赖于此工作负载的工作负载（上游）的恢复目标和可用性期望是什么？
1. 选择使此工作负载能够满足上游依赖项要求的恢复目标
1. 根据下游依赖项的恢复能力，选择可实现的恢复目标。非关键的下游依赖项（您可以“绕过”它们）可以排除。或者，处理关键的下游依赖项，在必要时提高其恢复能力。
**其他问题**
考虑以下问题，以及它们如何应用于此工作负载：
1. 根据中断类型（区域与可用区等），您是否有不同的 RTO 和 RPO？
1. 您的 RTO/RPO 是否会在特定时间（季节性、销售活动、产品发布）发生变化？ 如果是这样，不同的测量和时间边界是什么？
1. 如果工作负载中断，会有多少客户受到影响？
1. 如果工作负载中断，对声誉有何影响？
1. 如果工作负载中断，可能会产生哪些其他运营影响？ 例如，如果电子邮件系统不可用或工资单系统无法提交事务，则会影响员工的工作效率。
1. 工作负载 RTO 和 RPO 如何与业务线和组织 DR 策略保持一致？
1. 是否存在提供服务的内部合同义务？ 不履行这些义务会受到处罚吗？
1. 数据的监管或合规性约束是什么？
## 实施工作表
您可以将此工作表用于实施步骤 2 和 3。您可以调整此工作表以满足您的特定需求，例如添加其他问题。
![\[工作表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/worksheet.png)
**实施计划的工作量级别： **低
## 资源
**相关最佳实践：**
+ [REL09-BP04 定期执行数据恢复以验证备份完整性和流程](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 测试灾难恢复实施以验证实施效果](rel_planning_for_recovery_dr_tested.md)
**相关文档：**
+ [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [使用 AWS Resilience Hub 管理弹性策略](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**相关视频：**
+ [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4)
+ [AWS 上工作负载的灾难恢复](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 使用定义的恢复策略来实现恢复目标
定义满足工作负载恢复目标的灾难恢复（DR, disaster recovery）策略。选择一种策略，例如：备份和还原；备用（主动/被动）；或主动/主动。
DR 策略依赖于在主位置无法运行工作负载的情况下，在恢复站点中支持工作负载的能力。最常见的恢复目标是 RTO 和 RPO，相关讨论内容位于 [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md).
跨单个 AWS 区域 内的多个可用区（AZ）的 DR 策略可以缓解火灾、洪水和重大停电等灾难事件。如果需要实施保护措施，为工作负载无法在给定 AWS 区域 中运行这种不太可能发生的事件提供保护，您可以使用跨多个区域的 DR 策略。
在跨多个区域构建 DR 策略时，您应该选择以下策略之一。这些策略按成本和复杂性升序排列，按 RTO 和 RPO 降序排列。 *恢复区域* 指的是 AWS 区域，而不是用于工作负载的主要区域。
![\[显示 DR 策略的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **备份和还原** （RPO 以小时为单位，RTO 为 24 小时或以内）：将您的数据和应用程序备份到恢复区域。使用自动或连续备份可以实现时间点故障恢复，在某些情况下，可以将 RPO 降低到 5 分钟。在发生灾难的情况下，您将部署基础设施（使用基础设施即代码来减少 RTO）、部署代码并还原备份的数据，以便在恢复区域从灾难中恢复。
+ **指示灯** （RPO 以分钟为单位，RTO 为数十分钟）：在恢复区域中预置核心工作负载基础设施的副本。将您的数据复制到恢复区域并在那里创建数据备份。支持数据复制和备份所需的资源（如数据库和对象存储）始终处于启用状态。其他元素（如应用程序服务器或无服务器计算）未部署，但可以在需要时使用必要的配置和应用程序代码创建。
+ **热备用** （RPO 以秒为单位，RTO 以分钟为单位）：保证在恢复区域中始终运行缩减但功能齐全版本的工作负载。业务关键型系统是完全重复，而且始终可用的系统，只是其队列的规模经过缩减。数据在恢复区域中复制并留存。在需要恢复时，系统会快速扩展以处理生产负载。热备用系统的规模越大，RTO 和控制面板依赖度就越低。当完全扩展时，这称为 **热备用服务器**。
+ **多区域（多站点）主动-主动** （RPO 接近于零，RTO 可能为零）：您的工作负载被部署到多个 AWS 区域，并且主动处理来自这些区域的流量。此策略要求您跨区域同步数据。必须避免或处理在两个不同区域副本中写入同一记录可能引起的冲突，这会很复杂。数据复制对于数据同步非常有用，并且可以防止某些类型的灾难，但是它不能防止数据损坏或破坏，除非您的解决方案还包含时间点故障恢复选项。
**注意**
指示灯和热备用之间的差异有时难以区分。两者都在恢复区域中包含一个环境，其中具有主区域资产的副本。区别在于，如果不先采取额外措施，指示灯无法处理请求，而热备用可以立即处理流量（容量级别降低）。指示灯将要求您启用服务器，可能需要部署额外的（非核心）基础设施并纵向扩展，而热备用只需要您纵向扩展（所有内容都已部署并运行）。根据您的 RTO 和 RPO 需求在两者之间进行选择。
**期望结果：**
对于每个工作负载，都有一个已定义和实施的 DR 策略，使该工作负载能够实现 DR 目标。工作负载之间的 DR 策略利用可重用模式（如前面描述的策略）。
**常见反模式：**
+ 为具有类似 DR 目标的工作负载实施不一致的恢复过程。
+ 在发生灾难时临时实施 DR 策略。
+ 没有 DR 计划。
+ 恢复期间依赖于控制面板操作。
**建立此最佳实践的好处：**
+ 通过定义恢复策略，您可以使用常用工具和测试步骤。
+ 通过使用定义的恢复策略，可以在团队之间更高效地共享知识，并更容易地在他们自己的工作负载上实施 DR。
**未建立此最佳实践暴露的风险等级：** 高
+ 若没有经过计划、实施和测试的 DR 策略，在发生灾难时不太可能实现恢复目标。
## 实施指导
对于每个步骤，请参见下面的详细信息。
1. 确定将满足此工作负载恢复要求的 DR 策略。
1. 查看如何实施所选 DR 策略的模式。
1. 评估工作负载的资源，以及失效转移之前（正常操作期间）恢复区域中的资源配置。
1. 确定并实施措施，让恢复区域在需要时（在灾难事件期间）可以进行失效转移。
1. 确定并实施措施，以在需要时（在灾难事件期间）可以重新路由流量进行失效转移。
1. 设计工作负载的故障恢复计划。
**实施步骤**
1. **确定将满足此工作负载恢复要求的 DR 策略。**
选择 DR 策略是在减少停机时间和数据丢失（RTO 和 RPO）与策略实施的成本和复杂性之间进行权衡。您应该避免实施比所需策略更严格的策略，因为这会产生不必要的成本。
例如，在下图中，企业已经确定了他们允许的最大 RTO 以及他们可以在服务恢复策略上花费的费用限额。鉴于企业目标，指示灯或热备用这样的 DR 策略将同时满足 RTO 和成本标准。
![\[显示根据 RTO 和成本选择 DR 策略的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
如需了解更多信息，请参阅 [业务连续性计划（BCP，Business Continuity Plan）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)。
1. **查看如何实施所选 DR 策略的模式。**
这一步是了解如何实施所选策略。这些策略可以解释为使用多个 AWS 区域 作为主要站点和恢复站点。不过，您也可以选择使用单个区域内的多个可用区作为 DR 策略，这将利用多个策略的元素。
在这一步之后的后续步骤中，您将对特定的工作负载应用策略。
**备份和还原**
*备份和还原* 是实施起来最简单的策略，但需要更多时间和工作来恢复工作负载，从而导致更高的 RTO 和 RPO。最好的做法是，始终备份数据并将数据备份复制到另一个站点（如另一个 AWS 区域）。
![\[显示备份和还原架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
有关此策略的更多详细信息，请参阅 [AWS 上的灾难恢复（DR）架构，第 II 部分：使用快速恢复功能的备份与还原](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。
**指示灯**
利用 *指示灯* 方法，您可以将数据从主要区域复制到恢复区域。用于工作负载基础设施的核心资源部署在恢复区域中，但仍需要额外的资源和所有依赖项才能使此恢复区域成为功能堆栈。例如，在图 20 中，没有部署计算实例。
![\[显示指示灯架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
有关此策略的更多详细信息，请参阅 [AWS 上的灾难恢复（DR）架构，第 III 部分：指示灯和热备用](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
**热备用**
热 *备用* 方法涉及到确保在另一个区域中存在生产环境的规模缩减但功能齐全的副本。这种方法扩展了指示灯概念并减少了恢复时间，因为您的工作负载始终在另一个区域中运行。如果恢复区域以满容量部署，那么这种方式称为 *热备用服务器*。
![\[显示热备用架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
使用热备用或指示灯需要扩展恢复区域中的资源。为确保在需要时有可用的容量，请考虑使用 EC2 实例的 [容量预留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) 。如果使用 AWS Lambda，那么 [预置并发](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) 可以确保执行环境，以便它们准备好立即响应函数的调用。
有关此策略的更多详细信息，请参阅 [AWS 上的灾难恢复（DR）架构，第 III 部分：指示灯和热备用](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
**多站点主动/主动**
作为 *多站点主动/主动* 策略的一部分，您可以在多个区域中同时运行工作负载。多站点主动/主动策略处理来自其部署到的所有区域的流量。客户可能会出于 DR 以外的原因选择此策略。此策略可以用于提高可用性，或者在向全球受众部署工作负载时（使端点更靠近用户和/或部署针对该区域受众的本地化堆栈）使用此策略。作为一种 DR 策略，如果工作负载在部署此策略的某个 AWS 区域 中不能得到支持，那么该区域将被撤出，使用其余区域维护可用性。多站点主动/主动策略是 DR 策略中操作最复杂的策略，只有在业务需求时才应选择它。
![\[显示多站点主动/主动架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
有关此策略的更多详细信息，请参阅 [AWS 上的灾难恢复（DR，Disaster Recovery）架构，第 IV 部分：多站点主动/主动](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)。
**其他保护数据的实践**
对于所有这些策略，您还必须减轻数据灾难的影响。持续的数据复制可以防止某些类型的灾难，但它可能无法防止数据损坏或破坏，除非您的策略还包括存储数据的版本控制或用于时间点故障恢复的选项。除了副本之外，您还必须备份恢复站点中的复制数据以创建时间点备份。
**使用单个 AWS 区域 内的多个可用区（AZ）**
使用单个区域内的多个 AZ 时，您的 DR 实施会使用上述策略的多个元素。首先，您必须使用多个 AZ 创建一个高可用性（HA，High Availability）架构，如图 23 所示。此架构使用多站点主动/主动方法，因为 [Amazon EC2 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) 和 [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) 在多个 AZ 中部署了资源，主动处理请求。此架构还演示了热备用服务器方法，如果主 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 实例出现故障（或 AZ 本身出现故障），则备用实例将提升为主实例。
![\[显示多可用区架构的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
除了这种 HA 架构之外，您还需要添加运行工作负载所需的所有数据的备份。这对于限制在单个区的数据尤其重要，例如 [Amazon EBS 卷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) 或者 [Amazon Redshift 集群](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html)。如果一个 AZ 发生故障，您需要将这些数据恢复到另一个 AZ。如果可能，您还应该将数据备份复制到另一个 AWS 区域，作为额外的保护层。
下面的博客文章中介绍了一种不太常见的单区域多可用区 DR 的替代方法： [使用 Amazon Route 53 Application Recovery Controller 构建高弹性应用程序，第 1 部分：单区域堆栈](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)。这里的策略是尽可能保持 AZ 之间的隔离，就像区域的运作方式一样。使用这种替代策略，您可以选择主动/主动或主动/被动方法。
注意：某些工作负载具有数据驻留法规要求。如果这适用于当前只有一个 AWS 区域的位置的工作负载，那么多区域将不适合您的业务需求。多可用区策略可以很好地抵御大多数灾难。
1. **评估工作负载的资源，以及失效转移之前（正常操作期间）恢复区域中的资源配置。**
对于基础设施和 AWS 资源，使用基础设施即代码功能（如 [AWS CloudFormation](https://aws.amazon.com/cloudformation) ）或第三方工具（如 Hashicorp Terraform）。要使用单个操作跨多个账户和区域部署，您可以使用 [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)。对于多站点主动/主动和热备用服务器策略，恢复区域中部署的基础设施具有与主区域相同的资源。对于指示灯和热备用策略，部署的基础设施将需要额外的操作才可用于生产。使用 CloudFormation [参数](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) 和 [条件逻辑](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)，您可以通过单个模板控制部署的堆栈是活动的还是备用的。此 CloudFormation 模板示例见 [这篇博客文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)。
所有 DR 策略都要求在 AWS 区域 内备份数据源，然后将这些备份复制到恢复区域。[AWS Backup](https://aws.amazon.com/backup/) 提供了一个集中视图，您可以在其中配置、调度和监控这些资源的备份。对于指示灯、热备用和多站点主动/主动方法，您还应该将数据从主区域复制到恢复区域中的数据资源，例如 [Amazon Relational Database Service（Amazon RDS）](https://aws.amazon.com/rds) 数据库实例或 [Amazon DynamoDB](https://aws.amazon.com/dynamodb) 表。因此，这些数据资源处于活动状态，可以随时处理恢复区域中的请求。
要了解更多关于 AWS 服务如何跨区域运行的信息，请参阅以下博客系列： [使用 AWS 服务创建多区域应用程序](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)。
1. **确定并实施措施，让恢复区域在需要时（在灾难事件期间）可以进行失效转移。**
对于多站点主动/主动策略，失效转移意味着撤离一个区域，并依赖剩余的活动区域。通常，这些区域已准备好接受流量。对于指示灯和热备用策略，恢复操作将需要部署缺失的资源（如图 20 中的 EC2 实例），以及任何其他缺失的资源。
对于上述所有策略，您可能需要将数据库的只读实例提升为主读/写实例。
对于备份和还原，从备份中还原数据时会为该数据创建资源，例如 EBS 卷、RDS 数据库实例和 DynamoDB 表。您还需要还原基础设施并部署代码。您可以使用 AWS Backup 来还原恢复区域中的数据。请参阅 [REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据](rel_backing_up_data_identified_backups_data.md) 了解更多详细信息。重建基础设施包括创建资源，例如，EC2 实例以及所需的 [Amazon Virtual Private Cloud（Amazon VPC）、](https://aws.amazon.com/vpc)子网和安全组。您可以自动执行大部分还原过程。要了解具体方法，请参阅 [这篇博客文章](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)。
1. **确定并实施措施，以在需要时（在灾难事件期间）可以重新路由流量进行失效转移。**
此失效转移操作可以自动或手动启动。应谨慎使用基于运行状况检查或警报自动启动的失效转移，因为不必要的失效转移（误报）会产生不可用和数据丢失等成本。因此，通常会手动启动的失效转移。在这种情况下，您仍然应该自动执行失效转移步骤，这样手动启动就像按一下按钮一样简单。
在使用 AWS 服务时，需要考虑几个流量管理选项。一种选项是使用 [Amazon Route 53](https://aws.amazon.com/route53)。使用 Amazon Route 53，您可以将一个或多个 AWS 区域 中的多个 IP 端点与一个 Route 53 域名相关联。要实施手动启动的失效转移，您可以使用 [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/)，它提供高度可用的数据面板 API 以将流量重新路由到恢复区域。实施失效转移时，使用数据面板操作并避免控制面板操作，如 [REL11-BP04 恢复期间依赖于数据面板而不是控制面板](rel_withstand_component_failures_avoid_control_plane.md).
要了解有关此选项和其他选项的更多信息，请参阅 [灾难恢复白皮书的这一部分](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)。
1. **设计工作负载的故障恢复计划。**
故障恢复是指在灾难事件消除后将工作负载操作返回主区域。向主区域预置基础设施和代码通常遵循最初使用的相同步骤，依赖于基础设施即代码和代码部署管道。故障恢复的挑战是还原数据存储，并确保它们与运行中的恢复区域保持一致。
在失效转移状态下，恢复区域中的数据库处于活动状态，并且具有最新数据。然后，目标是从恢复区域重新同步到主区域，确保主区域是最新的。
某些 AWS 服务会自动执行此操作。如果使用 [Amazon DynamoDB 全局表](https://aws.amazon.com/dynamodb/global-tables/)，即使主区域中的表不可用，当它重新联机时，DynamoDB 也会继续传播任何挂起的写操作。如果使用 [Amazon Aurora 全局数据库](https://aws.amazon.com/rds/aurora/global-database/) 并使用 [托管的计划失效转移](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)，则维护 Aurora 全局数据库的现有复制拓扑。因此，主区域中以前的读/写实例将成为副本，并从恢复区域接收更新。
如果这不是自动执行的，您将需要在主区域中重新建立数据库，作为恢复区域中数据库的副本。在许多情况下，这将涉及删除旧的主数据库，然后创建新的副本。例如，有关如何使用 Amazon Aurora 全局数据库对 *计划外* 失效转移执行此操作的说明，请参阅下面的实验： [全局数据库的故障恢复](https://awsauroralabsmy.com/global/failback/)。
失效转移后，如果您可以继续在恢复区域中运行，请考虑将此区域设为新的主区域。您仍然需要执行上述所有步骤，将以前的主区域变成恢复区域。有些组织会进行定期轮换，定期交换其主区域和恢复区域（例如每三个月一次）。
失效转移和故障恢复所需的所有步骤都应保存在行动手册且可供所有团队成员使用，并定期进行审查。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 恢复期间依赖于数据面板而不是控制面板](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 定义停机和数据丢失的恢复目标](rel_planning_for_recovery_objective_defined_recovery.md)
**相关文档：**
+ [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [云中的灾难恢复选项](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [在一小时内构建无服务器多区域、主动-主动后端解决方案](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [多区域无服务器后端 – 重新加载](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS：跨区域复制只读副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53：配置 DNS 故障转移](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3：跨区域复制](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [什么是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [什么是 Route 53 Application Recovery Controller？](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS 弹性灾难恢复](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform：入门 – AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**相关视频：**
+ [AWS 上工作负载的灾难恢复](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4)
+ [开始使用 AWS 弹性灾难恢复 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**相关示例：**
+ [AWS Well-Architected 实验 – 灾难恢复](https://wellarchitectedlabs.com/reliability/disaster-recovery/) – 说明 DR 策略的系列研讨会
# REL13-BP03 测试灾难恢复实施以验证实施效果
定期测试到恢复站点的失效转移，以确保正常运行，并满足 RTO 和 RPO。
要避免的模式是制定了恢复路径但很少测试。例如，您可能有一个用于只读查询的辅助数据存储。当您写入某个数据存储，却发现主存储故障时，您可能希望将故障转移到辅助数据存储。如果您不经常测试此故障转移，可能会发现您关于辅助数据存储容量的假设是错误的。辅助数据存储容量在您上次测试时可能是足够的，但可能无法再容纳这次情况下的负载。我们的经验表明，唯一有效的错误恢复是您经常测试的路径。因此，最好只开发几条恢复路径。您可以建立恢复模式并定期对其进行测试。如果恢复路径比较复杂或至关重要，您仍需定期在生产环境中测试该故障，确保恢复路径有效。在我们刚才讨论的示例中，您应该定期将故障转移到备用存储，无论是否有需要。
**常见反模式：**
+ 从不在生产环境中测试失效转移。
**建立此最佳实践的好处：** 定期测试您的灾难恢复计划，确保该计划在需要时能够正常发挥作用，并且您的团队知道如何执行该策略。
**未建立此最佳实践暴露的风险等级：** 高
## 实施指导
+ 为灾难恢复设计工作负载。定期测试恢复路径：面向恢复的计算可识别系统中能够增强恢复功能的特性。这些特性包括：隔离和冗余，系统范围回滚更改的能力，监控并确定运行状况的能力，提供诊断、自动恢复、模块化设计的能力，以及重启的能力。练习恢复路径，以确保您可以在指定时间内恢复到指定状态。在此恢复过程中使用运行手册来记录问题，并在下一次测试之前找到问题的解决方案。
+ [加州大学伯克利分校/斯坦福大学的面向恢复的计算项目](http://roc.cs.berkeley.edu/)
+ 使用 CloudEndure Disaster Recovery 来实施和测试您的 DR 策略。
+ [使用 CloudEndure 测试灾难恢复解决方案](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS 的 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## 资源
**相关文档：**
+ [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [使用 CloudEndure 测试灾难恢复解决方案](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [加州大学伯克利分校/斯坦福大学的面向恢复的计算项目](http://roc.cs.berkeley.edu/)
+ [什么是 AWS Fault Injection Simulator？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**相关视频：**
+ [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019：AWS 的备份与还原，以及灾难恢复解决方案（STG208）](https://youtu.be/7gNXfo5HZN8)
**相关示例：**
+ [AWS Well-Architected 实验 – 测试弹性](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 管理 DR 站点或区域的配置偏差
确保 DR 站点或区域的基础设施、数据和配置满足需求。例如，检查 AMI 和服务限额是否为最新。
AWS Config 会持续监控和记录 AWS 资源配置。它可以检测到偏差并触发 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 进行修复和发出警报。AWS CloudFormation 还可以在您已部署的堆栈中检测到偏差。
**常见反模式：**
+ 在主位置进行配置或基础设施更改时，未能在恢复位置进行更新。
+ 不考虑主位置和恢复位置的潜在限制（如服务区别）。
**建立此最佳实践的好处：** 确保您的 DR 环境与现有环境一致，可保证完整恢复。
**未建立这种最佳实践的情况下暴露的风险等级：** 中
## 实施指导
+ 确保您的交付管道可交付到主站点和备份站点。用于将应用程序部署到生产中的交付管道必须分布到所有指定的灾难恢复策略位置，包括开发和测试环境。
+ 启用 AWS Config 来跟踪潜在偏差位置。使用 AWS Config 规则来创建可强制实施灾难恢复策略并在检测到偏差时生成提醒的系统。
+ [按照 AWS Config 规则 修正不合规 AWS 资源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ 使用 AWS CloudFormation 部署基础设施。AWS CloudFormation 可以检测 CloudFormation 模板指定的内容和实际部署内容之间的偏差。
+ [AWS CloudFormation：在整个 CloudFormation 堆栈上检测偏差](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## 资源
**相关文档：**
+ [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation：在整个 CloudFormation 堆栈上检测偏差](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [如何在 AWS 上实施基础设施配置管理解决方案？](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [按照 AWS Config 规则 修正不合规 AWS 资源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**相关视频：**
+ [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 自动执行恢复
利用 AWS 或第三方工具自动进行系统恢复，并将流量路由至 DR 站点或区域。
根据已配置的运行状况检查，Elastic Load Balancing 和 AWS Auto Scaling 等 AWS 服务可将负载分配到运行正常的可用区，而 Amazon Route 53 和 AWS Global Accelerator 等服务则可将负载路由到运行正常的 AWS 区域。Amazon Route 53 Application Recovery Controller 可帮助您使用就绪检查和路由控制功能来管理和协调失效转移操作。这些功能持续监控您的应用程序从故障中恢复的能力，因此您可以跨多个 AWS 区域、可用区和本地部署控制您的应用程序恢复。
对于现有的物理或虚拟数据中心或私有云上的工作负载， [AWS 弹性灾难恢复](https://aws.amazon.com/cloudendure-disaster-recovery/)（通过 AWS Marketplace 提供）使组织能够设置自动向 AWS 进行灾难恢复的策略。CloudEndure 还支持 AWS 中的跨区域/跨可用区灾难恢复。
**常见反模式：**
+ 实施相同的自动故障转移和故障恢复可能会导致在故障时发生摆动。
**建立此最佳实践的好处：** 自动恢复通过消除发生手动错误的可能性来缩短恢复时间。
**未建立这种最佳实践的情况下暴露的风险等级：** 中
## 实施指导
+ 恢复路径自动化。如果恢复时间很短，人工判断和操作无法用于可用性非常高的场景。在这种情况下，系统每次必须自动进行恢复。
+ 使用 CloudEndure Disaster Recovery 自动执行失效转移和故障恢复操作。CloudEndure Disaster Recovery 可持续将您的计算机（包括操作系统、系统状态配置、数据库、应用程序和文件）复制到目标 AWS 账户和首选区域中的低成本暂存区域。在发生灾难时，您可以指示 CloudEndure Disaster Recovery 在几分钟内自动启动数千台处于完全预置状态的计算机。
+ [执行灾难恢复故障转移和故障恢复](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## 资源
**相关文档：**
+ [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 的 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**相关视频：**
+ [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4)