REL13-BP02 使用定义的恢复策略来实现恢复目标
定义满足工作负载恢复目标的灾难恢复（DR）策略。选择一种策略，例如备份和还原、备用（主动/被动）或主动/主动。
期望结果：对于每个工作负载，都有一个已定义和实施的 DR 策略，使该工作负载能够实现 DR 目标。工作负载之间的 DR 策略利用可重用模式（例如，前面描述的策略）。
常见反模式：
-
为具有类似 DR 目标的工作负载实施不一致的恢复过程。
-
在发生灾难时临时实施 DR 策略。
-
没有针对灾难恢复的计划。
-
恢复期间依赖于控制面板操作。
建立此最佳实践的好处：
-
通过定义恢复策略，您可以使用常用工具和测试步骤。
-
使用定义的恢复策略，改进团队之间的知识共享，并在他们自己的工作负载上实施 DR。
在未建立这种最佳实践的情况下暴露的风险等级：高。若没有经过计划、实施和测试的 DR 策略，在发生灾难时不太可能实现恢复目标。
实施指导
DR 策略依赖于在主位置无法运行工作负载的情况下，在恢复站点中支持工作负载的能力。最常见的恢复目标是 RTO 和 RPO，相关讨论内容位于 REL13-BP01 定义停机和数据丢失的恢复目标。
跨单个 AWS 区域 内的多个可用区（AZ）的 DR 策略可以缓解火灾、洪水和重大停电等灾难事件。如果需要实施保护措施，为工作负载无法在给定 AWS 区域 中运行这种不太可能发生的事件提供保护，您可以使用跨多个区域的 DR 策略。
在跨多个区域构建 DR 策略时，您应该选择以下策略之一。这些策略按成本和复杂性升序排列，按 RTO 和 RPO 降序排列。 恢复区域指的是 AWS 区域，而不是用于工作负载的主要区域。
图 17：灾难恢复（DR）策略
-
备份和还原（RPO 以小时为单位，RTO 为 24 小时或更短）：将您的数据和应用程序备份到恢复区域。使用自动或连续备份可以实现时间点故障恢复，在某些情况下，可以将 RPO 降低到 5 分钟。在发生灾难的情况下，您将部署基础设施（使用基础设施即代码来减少 RTO）、部署代码并还原备份的数据，以便在恢复区域从灾难中恢复。
-
指示灯（RPO 以分钟为单位，RTO 为数十分钟）：在恢复区域中预置核心工作负载基础设施的副本。将您的数据复制到恢复区域并在那里创建数据备份。支持数据复制和备份所需的资源（如数据库和对象存储）始终处于启用状态。其他元素（如应用程序服务器或无服务器计算）未部署，但可以在需要时使用必要的配置和应用程序代码创建。
-
热备用（RPO 以秒为单位，RTO 以分钟为单位）：保证在恢复区域中始终运行缩减但功能齐全版本的工作负载。业务关键型系统是完全重复，而且始终可用的系统，只是其队列的规模经过缩减。数据在恢复区域中复制并留存。在需要恢复时，系统会快速扩展以处理生产负载。热备用的规模越大，RTO 和控制面板依赖度就越低。当完全扩展时，这称为热备用服务器。
-
多区域（多站点）主动-主动（RPO 接近于零，RTO 可能为零）：您的工作负载部署到多个 AWS 区域，并且主动处理来自这些区域的流量。此策略要求您跨区域同步数据。必须避免或处理在两个不同区域副本中写入同一记录可能引起的冲突，这会很复杂。数据复制对于数据同步非常有用，并且可以防止某些类型的灾难，但是它不能防止数据损坏或破坏，除非您的解决方案还包含时间点故障恢复选项。
注意
指示灯和热备用之间的差异有时难以区分。两者都在恢复区域中包含一个环境，其中具有主区域资产的副本。区别在于，如果不先采取额外措施，指示灯无法处理请求，而热备用可以立即处理流量（容量级别降低）。指示灯将要求您启用服务器，可能需要部署额外的（非核心）基础设施并纵向扩展，而热备用只需要您纵向扩展（所有内容都已部署并运行）。根据您的 RTO 和 RPO 需求在两者之间进行选择。
当成本是一个问题，并且您希望实现与热备用策略中定义的类似 RPO 和 RTO 目标时，您可以考虑云原生解决方案（例如，AWS Elastic Disaster Recovery），该解决方案采用指示灯方法并提供改进的 RPO 和 RTO 目标。
实施步骤
-
确定将满足此工作负载恢复要求的 DR 策略。
选择 DR 策略是在减少停机时间和数据丢失（RTO 和 RPO）与策略实施的成本和复杂性之间进行权衡。您应该避免实施比所需策略更严格的策略，因为这会产生不必要的成本。
例如，在下图中，企业已经确定了他们允许的最大 RTO 以及他们可以在服务恢复策略上花费的费用限额。鉴于企业目标，指示灯或热备用这样的 DR 策略将同时满足 RTO 和成本标准。
图 18：根据 RTO 和成本选择 DR 策略
如需了解更多信息，请参阅业务连续性计划（BCP）
-
查看如何实施所选 DR 策略的模式。
这一步是了解如何实施所选策略。这些策略可以解释为使用多个 AWS 区域 作为主要站点和恢复站点。不过，您也可以选择使用单个区域内的多个可用区作为 DR 策略，这将利用多个策略的元素。
在后续步骤中，您可以对特定的工作负载应用策略。
备份和还原
备份和还原是实施起来最简单的策略，但需要更多时间和工作来恢复工作负载，从而导致更高的 RTO 和 RPO。最好的做法是，始终备份数据并将数据备份复制到另一个站点（如另一个 AWS 区域）。
图 19：备份和还原架构
有关此策略的更多详细信息，请参阅 AWS 上的灾难恢复（DR）架构，第 II 部分：使用快速恢复功能的备份与还原
指示灯
利用指示灯方法，您可以将数据从主要区域复制到恢复区域。用于工作负载基础设施的核心资源部署在恢复区域中，但仍需要额外的资源和所有依赖项才能使此恢复区域成为功能堆栈。例如，在图 20 中，没有部署计算实例。
图 20：指示灯架构
有关此策略的更多详细信息，请参阅 AWS 上的灾难恢复（DR）架构，第 III 部分：指示灯和热备用
热备用
热备用方法涉及到确保在另一个区域中存在生产环境的规模缩减但功能齐全的副本。这种方法扩展了指示灯概念并减少了恢复时间，因为您的工作负载始终在另一个区域中运行。如果以全部容量部署恢复区域，那么这种方式称为热备用。
图 21：热备用架构
使用热备用或指示灯需要扩展恢复区域中的资源。为确保在需要时有可用的容量，请考虑使用 EC2 实例的容量预留。如果使用 AWS Lambda，那么预置并发可以提供执行环境，以便它们准备好立即响应函数的调用。
有关此策略的更多详细信息，请参阅 AWS 上的灾难恢复（DR）架构，第 III 部分：指示灯和热备用
多站点主动/主动
作为多站点主动/主动策略的一部分，您可以在多个区域中同时运行工作负载。多站点主动/主动策略处理来自其部署到的所有区域的流量。客户可能会出于 DR 以外的原因选择此策略。此策略可以用于提高可用性，或者在向全球受众部署工作负载时（使端点更靠近用户和/或部署针对该区域受众的本地化堆栈）使用此策略。作为一种 DR 策略，如果工作负载在部署此策略的某个 AWS 区域 中不能得到支持，那么该区域将被撤出，使用其余区域维持可用性。多站点主动/主动策略是 DR 策略中操作最复杂的策略，只有在业务需求时才应选择它。
图 22：多站点主动/主动架构
有关此策略的更多详细信息，请参阅 AWS 上的灾难恢复（DR）架构，第 IV 部分：多站点主动/主动
AWS Elastic Disaster Recovery
如果您正考虑为灾难恢复使用指示灯或热备用策略，AWS Elastic Disaster Recovery 可以提供一种带来更多好处的替代方法。Elastic Disaster Recovery 可以提供类似于热备用方法的 RPO 和 RTO 目标，同时保持指示灯方法的低成本。Elastic Disaster Recovery 将数据从主区域复制到恢复区域，使用持续数据保护来实现以秒为单位的 RPO 和以分钟为单位的 RTO。在恢复区域中仅部署复制数据所需的资源，从而降低成本，类似于指示灯策略。使用 Elastic Disaster Recovery 时，如果在失效转移或演练过程中启动，则服务会协调和编排计算资源的恢复。
图 23：AWS Elastic Disaster Recovery 架构
其他保护数据的实践
对于所有这些策略，您还必须减轻数据灾难的影响。持续的数据复制可以防止某些类型的灾难，但它可能无法防止数据损坏或破坏，除非您的策略还包括存储数据的版本控制或用于时间点故障恢复的选项。除了副本之外，您还必须备份恢复站点中的复制数据以创建时间点备份。
使用单个 AWS 区域 内的多个可用区（AZ）
使用单个区域内的多个可用区时，您的 DR 实施会使用上述策略的多个元素。首先，您必须使用多个可用区创建一个高可用性（HA）架构，如图 23 所示。此架构使用多站点主动/主动方法，因为 Amazon EC2 实例和 Elastic Load Balancer 在多个可用区中部署了资源，主动处理请求。此架构还演示了热备用服务器方法，如果主 Amazon RDS 实例出现故障（或可用区本身出现故障），则备用实例将提升为主实例。
图 24：多可用区架构
除了这种 HA 架构之外，您还需要添加运行工作负载所需的所有数据的备份。这对于限制在单个区的数据尤其重要，例如 Amazon EBS 卷或 Amazon Redshift 集群。如果一个可用区发生故障，您需要将这些数据恢复到另一个可用区。如果可能，您还应该将数据备份复制到另一个 AWS 区域，提供另一层保护。
下面的博客文章中介绍了一种不太常见的单区域多可用区 DR 的替代方法：使用 Amazon Route 53 Application Recovery Controller 构建高弹性应用程序，第 1 部分：单区域堆栈
注意
某些工作负载具有数据驻留法规要求。如果这适用于当前只有一个 AWS 区域的位置的工作负载，那么多区域将不适合您的业务需求。多可用区策略可以很好地抵御大多数灾难。
-
评估工作负载的资源，以及失效转移之前（正常操作期间）恢复区域中的资源配置。
对于基础设施和 AWS 资源，使用基础设施即代码功能（如 AWS CloudFormation
所有 DR 策略都要求在 AWS 区域内备份数据源，然后将这些备份复制到恢复区域。AWS Backup
要了解更多关于 AWS 服务如何跨区域运行的信息，请参阅以下博客系列：使用 AWS 服务创建多区域应用程序
-
确定并实施措施，让恢复区域在需要时（在灾难事件期间）可以进行失效转移。
对于多站点主动/主动策略，失效转移意味着撤离一个区域，并依赖剩余的活动区域。通常，这些区域已准备好接受流量。对于指示灯和热备用策略，恢复操作将需要部署缺失的资源（如图 20 中的 EC2 实例），以及任何其他缺失的资源。
对于上述所有策略，您可能需要将数据库的只读实例提升为主读/写实例。
对于备份和还原，从备份中还原数据时会为该数据创建资源，例如 EBS 卷、RDS 数据库实例和 DynamoDB 表。您还需要还原基础设施并部署代码。您可以使用 AWS Backup 来还原恢复区域中的数据。请参阅 REL09-BP01 识别和备份需要备份的所有数据，或从源复制数据 了解更多详细信息。重建基础设施包括创建资源，例如，EC2 实例以及所需的 Amazon Virtual Private Cloud（Amazon VPC）
-
确定并实施措施，以在需要时（在灾难事件期间）可以重新路由流量进行失效转移。
此失效转移操作可以自动或手动启动。应谨慎使用基于运行状况检查或警报自动启动的失效转移，因为不必要的失效转移（误报）会产生不可用和数据丢失等成本。因此，通常会使用手动启动的失效转移。在这种情况下，您仍然应该自动执行失效转移步骤，这样手动启动就像按一下按钮一样简单。
在使用 AWS 服务时，需要考虑几个流量管理选项。一个选项是使用 Amazon Route 53
要了解有关此选项及其他选项的更多信息，请参阅灾难恢复白皮书的这一部分。
-
设计工作负载的失效自动恢复计划。
失效自动恢复是指在灾难事件消除后将工作负载运营恢复到主区域。向主区域预置基础设施和代码通常遵循最初使用的相同步骤，依赖于基础设施即代码和代码部署管道。失效自动恢复面临的挑战是还原数据存储，并确保它们与运行中的恢复区域保持一致。
在失效转移状态下，恢复区域中的数据库处于活动状态，并且具有最新数据。然后，目标是从恢复区域重新同步到主区域，确保主区域是最新的。
某些 AWS 服务会自动执行此操作。如果使用 Amazon DynamoDB 全局表
如果这不是自动执行的，您将需要在主区域中重新建立数据库，作为恢复区域中数据库的副本。在许多情况下，这将涉及删除旧的主数据库，然后创建新的副本。例如，有关如何使用 Amazon Aurora 全局数据库对计划外失效转移执行此操作的说明，请参阅下面的实验：全局数据库的失效自动恢复
失效转移后，如果您可以继续在恢复区域中运行，请考虑将此区域设为新的主区域。您仍然需要执行上述所有步骤，将以前的主区域变成恢复区域。有些组织会进行定期轮换，定期交换其主区域和恢复区域（例如每三个月一次）。
失效转移和失效自动恢复所需的所有步骤都应保存在行动手册且可供所有团队成员使用，并定期进行审查。
使用 Elastic Disaster Recovery 时，服务会协助编排和自动执行失效自动恢复流程。有关更多详细信息，请参阅执行失效自动恢复。
实施计划的工作量级别：高
资源
相关最佳实践：
相关文档：
相关视频：
相关示例：
-
Well-Architected 实验室 - 灾难恢复
- 说明 DR 策略的系列研讨会
