REL13-BP02 使用定义的恢复策略来实现恢复目标

定义可满足工作负载恢复目标的灾难恢复（DR）策略。选择一种策略，例如备份和还原、备用（主动/被动）或主动/主动。

期望结果：每个工作负载都有已定义且实施的灾难恢复策略，可让该工作负载实现灾难恢复目标。工作负载之间的灾难恢复策略利用可重用模式（例如前面所述的策略）。

常见反模式：

为具有类似灾难恢复目标的工作负载实施不一致的恢复过程。
在发生灾难时临时实施灾难恢复策略。
没有针对灾难恢复的计划。
恢复期间依赖于控制面板操作。

建立此最佳实践的好处：

通过定义恢复策略，您可以使用常用工具和测试步骤。
使用定义的恢复策略可改善团队之间的知识共享情况，并在他们自己的工作负载上实施灾难恢复。

在未建立这种最佳实践的情况下暴露的风险等级：高。若没有经过计划、实施和测试的灾难恢复策略，发生灾难时就不太可能实现恢复目标。

实施指导

灾难恢复策略依赖于在主位置无法运行工作负载的情况下，在恢复站点中支持工作负载的能力。最常见的恢复目标是 RTO 和 RPO，如 REL13-BP01 定义停机和数据丢失的恢复目标中所述。

跨单个 AWS 区域内的多个可用区（AZ）的灾难恢复策略可以缓解火灾、洪水和重大停电等灾难事件造成的影响。如果需要实施保护措施，为工作负载无法在给定 AWS 区域中运行这种不太可能发生的事件提供保护，您可以使用跨多个区域的灾难恢复策略。

在跨多个区域构建灾难恢复策略时，您应该选择以下某个策略。这些策略按成本和复杂性升序排列，按 RTO 和 RPO 降序排列。恢复区域指的是 AWS 区域，而不是用于工作负载的主要区域。

图 17：灾难恢复（DR）策略

备份和还原（RPO 以小时为单位，RTO 为 24 小时或更短时间为单位）：将数据和应用程序备份到恢复区域。使用自动或连续备份可以实现时间点故障恢复（PITR），在某些情况下，可以将 RPO 降低到 5 分钟。在发生灾难的情况下，您将部署基础设施（使用基础设施即代码来减少 RTO）、部署代码并还原备份的数据，以便在恢复区域从灾难中恢复。
指示灯（RPO 以分钟为单位，RTO 以数十分钟为单位）：在恢复区域中预置核心工作负载基础设施的副本。将数据复制到恢复区域并在其中创建数据备份。支持数据复制和备份所需的资源（如数据库和对象存储）始终处于启用状态。其他元素（如应用程序服务器或无服务器计算）未部署，但可以在需要时使用必要的配置和应用程序代码创建。
温备用（RPO 以秒为单位，RTO 以分钟为单位）：保证在恢复区域中始终运行缩减但功能齐全版本的工作负载。业务关键型系统是完全重复且始终可用的系统，只是其队列的规模经过缩减。数据在恢复区域中复制并留存。在需要恢复时，系统会快速纵向扩展来处理生产负载。温备用的规模越大，RTO 和控制面板依赖度就越低。当完全扩展时，这称为热备用。
多区域（多站点）主动-主动（RPO 接近于零，RTO 可能为零）：工作负载部署到多个 AWS 区域，并且主动处理来自这些区域的流量。此策略要求您跨区域同步数据。必须避免或处理在两个不同区域副本中写入同一记录可能引起的冲突，因为这种情况很复杂。数据复制对于数据同步非常有用，并且可以防止某些类型的灾难，但是它不能防止数据损坏或破坏，除非您的解决方案还包含时间点故障恢复选项。

注意

指示灯和温备用之间的差异有时难以区分。两者都在恢复区域中包含一个环境，其中具有主区域资产的副本。区别在于，如果不先采取额外措施，指示灯无法处理请求，而温备用可以立即处理流量（容量级别降低）。指示灯将要求您启用服务器，可能需要部署额外的（非核心）基础设施并纵向扩展，而温备用只需要您纵向扩展（所有内容都已部署并运行）。根据 RTO 和 RPO 需求在两者之间进行选择。

如果需要考虑成本，并且希望实现与温备用策略中定义的类似 RPO 和 RTO 目标时，您可以考虑云原生解决方案（例如 AWS Elastic Disaster Recovery），此类解决方案会采用指示灯方法并提供改进的 RPO 和 RTO 目标。

实施步骤

确定可满足此工作负载恢复要求的灾难恢复策略。

选择灾难恢复策略是在减少停机时间和数据丢失（RTO 和 RPO）与策略实施的成本和复杂性之间进行权衡。应该避免实施比所需策略更严格的策略，因为这会产生不必要的成本。

例如，在下图中，企业已经确定了自己允许的最大 RTO 以及可在服务恢复策略上花费的费用限额。考虑到企业目标，指示灯或温备用这样的灾难恢复策略将同时满足 RTO 和成本标准。

图 18：根据 RTO 和成本选择灾难恢复策略

如需了解更多信息，请参阅业务连续性计划（BCP）。
查看如何实施所选灾难恢复策略的模式。

这一步是了解如何实施所选策略。这些策略可以解释为使用多个 AWS 区域作为主要站点和恢复站点。不过，您也可以选择使用单个区域内的多个可用区作为灾难恢复策略，这将利用多个策略的元素。

在后续步骤中，您可以对特定的工作负载应用策略。

备份和还原

备份和还原是实施起来最简单的策略，但需要更多时间和工作来恢复工作负载，导致更高的 RTO 和 RPO。最好的做法是，始终备份数据并将数据备份复制到另一个站点（例如另一个 AWS 区域）。

图 19：备份和还原架构

有关此策略的更多详细信息，请参阅《Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery》。

指示灯

利用指示灯方法，您可以将数据从主要区域复制到恢复区域。用于工作负载基础设施的核心资源部署在恢复区域中，但仍需要额外的资源和所有依赖项，才能让此恢复区域成为功能堆栈。例如，图 20 中就没有部署计算实例。

图 20：指示灯架构

有关此策略的更多详细信息，请参阅《Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby》。

温备用

温备用方法涉及到确保在另一个区域中存在生产环境的规模缩减但功能齐全的副本。这种方法扩展了指示灯概念并减少了恢复时间，因为工作负载始终在另一个区域中运行。如果以全部容量部署恢复区域，这种方式就称为热备用。

图 21：温备用架构

使用温备用或指示灯需要纵向扩展恢复区域中的资源。为确保在需要时有可用的容量，请考虑使用 EC2 实例的容量预留。如果使用 AWS Lambda，那么预置并发可以提供运行时环境，以便这些环境准备好立即响应函数的调用。

有关此策略的更多详细信息，请参阅《Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby》。

多站点主动/主动

作为多站点主动/主动策略的一部分，您可以在多个区域中同时运行工作负载。多站点主动/主动策略处理来自其部署到的所有区域的流量。客户可能会出于灾难恢复以外的原因选择此策略。此策略可以用于提高可用性，或者在向全球受众部署工作负载（使端点更靠近用户和/或部署针对该区域受众的本地化堆栈）时使用此策略。作为一种灾难恢复策略，如果工作负载在部署此策略的某个 AWS 区域中不能得到支持，那么该区域将被撤出，使用其余区域维持可用性。多站点主动/主动策略是灾难恢复策略中操作最复杂的策略，只有在业务要求需要时才应选择它。

图 22：多站点主动/主动架构

有关此策略的更多详细信息，请参阅《Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active》。

AWS Elastic Disaster Recovery

如果您正考虑为灾难恢复使用指示灯或温备用策略，AWS Elastic Disaster Recovery 可以提供一种带来更多好处的替代方法。弹性灾难恢复可以提供类似于温备用方法的 RPO 和 RTO 目标，同时保持指示灯方法的低成本。弹性灾难恢复将数据从主区域复制到恢复区域，使用持续数据保护来实现以秒为单位的 RPO 和以分钟为单位的 RTO。在恢复区域中仅部署复制数据所需的资源，从而降低成本，类似于指示灯策略。使用弹性灾难恢复时，如果在失效转移或演练过程中启动，则服务会协调并编排计算资源的恢复。

图 23：AWS Elastic Disaster Recovery 架构

其他保护数据的实践

对于所有这些策略，您还必须减轻数据灾难的影响。持续的数据复制可以防止某些类型的灾难，但它可能无法防止数据损坏或破坏，除非您的策略还包括存储数据的版本控制或用于时间点故障恢复的选项。除了副本之外，您还必须备份恢复站点中的复制数据以创建时间点备份。

使用单个 AWS 区域内的多个可用区（AZ）

使用单个区域内的多个可用区时，实施灾难恢复会用到上述策略的多个元素。首先，您必须使用多个可用区创建一个高可用性（HA）架构，如图 23 所示。此架构使用多站点主动/主动方法，因为 Amazon EC2 实例和弹性负载均衡器在多个可用区中部署了资源，主动处理请求。此架构还演示了热备用方法，如果主 Amazon RDS 实例出现故障（或可用区本身出现故障），则备用实例将提升为主实例。

图 24：多可用区架构

除了这种高可用性架构，您还需要添加运行工作负载所需的所有数据的备份。这对于限制在单个区的数据尤其重要，例如 Amazon EBS 卷或 Amazon Redshift 集群。如果一个可用区发生故障，您需要将这些数据恢复到另一个可用区。如果可能，您还应该将数据备份复制到另一个 AWS 区域，提供另一层保护。

下面的博客文章中介绍了一种不太常见的单区域多可用区灾难恢复的替代方法：Building highly resilient applications using Amazon Application Recovery Controller, Part 1: Single-Region stack。这里的策略是尽可能保持可用区之间的隔离，就像区域的运作方式一样。使用这种替代策略，您可以选择主动/主动或主动/被动方法。

注意
某些工作负载具有数据驻留法规要求。如果这适用于当前只有一个 AWS 区域的位置的工作负载，那么多区域将不适合您的业务需求。多可用区策略可以很好地抵御大多数灾难。
评测工作负载的资源，以及失效转移之前（正常操作期间）恢复区域中的资源配置。

对于基础设施和 AWS 资源，使用基础设施即代码功能（如 AWS CloudFormation）或第三方工具（如 Hashicorp Terraform）。要使用单个操作跨多个账户和区域部署，您可以使用 AWS CloudFormation StackSets。对于多站点主动/主动和热备用策略，恢复区域中部署的基础设施具有与主区域相同的资源。对于指示灯和温备用策略，部署的基础设施需要采取额外操作，才可用于生产。使用 CloudFormation 参数和条件逻辑，您可以通过单个模板控制部署的堆栈处于活动状态还是备用状态。使用弹性灾难恢复时，服务会复制并编排应用程序配置和计算资源的还原。

所有灾难恢复策略都要求在 AWS 区域内备份数据源，然后将这些备份复制到恢复区域。AWS Backup 提供了一个集中视图，可供您在其中配置、调度和监控这些资源的备份。对于指示灯、温备用和多站点主动/主动方法，您还应该将数据从主区域复制到恢复区域中的数据资源，例如 Amazon Relational Database Service（Amazon RDS）数据库实例或 Amazon DynamoDB 表。因此，这些数据资源处于活动状态，可以随时处理恢复区域中的请求。

要了解更多关于 AWS 服务如何跨区域运行的信息，请参阅博客系列文章《Creating a Multi-Region Application with AWS Services》。
确定并实施措施，让恢复区域在需要时（在灾难事件期间）可以进行失效转移。

对于多站点主动/主动策略，失效转移意味着撤离一个区域，并依赖剩余的活动区域。通常，这些区域已准备好接受流量。对于指示灯和温备用策略，恢复操作需要部署缺失的资源（如图 20 中的 EC2 实例），以及任何其他缺失的资源。

对于上述所有策略，您可能需要将数据库的只读实例提升为主读/写实例。

对于备份和还原，从备份中还原数据时会为该数据创建资源，例如 EBS 卷、RDS 数据库实例和 DynamoDB 表。您还需要还原基础设施并部署代码。您可以使用 AWS Backup 来还原恢复区域中的数据。有关更多信息，请参阅 REL09-BP01 识别并备份需要备份的所有数据或从源复制数据。重建基础设施包括创建资源，例如 EC2 实例以及所需的 Amazon Virtual Private Cloud（Amazon VPC）、子网和安全组。您可以自动执行大部分还原过程。要了解具体方法，请参阅这篇博客文章。
确定并实施措施，在需要时（在灾难事件期间）可以重新路由流量进行失效转移。

此失效转移操作可以自动或手动启动。应谨慎使用基于运行状况检查或警报自动启动的失效转移，因为不必要的失效转移（误报）会产生不可用和数据丢失等成本。因此，通常会使用手动启动的失效转移。在这种情况下，您仍然应该自动执行失效转移步骤，这样手动启动就像按一下按钮一样简单。

在使用 AWS 服务时，需要考虑几个流量管理选项。一个选项是使用 Amazon Route 53。使用 Amazon Route 53，您可以将一个或多个 AWS 区域中的多个 IP 端点与一个 Route 53 域名相关联。要实施手动启动的失效转移，您可以使用 Amazon 应用程序恢复控制器，利用其提供的高可用性数据面板 API 将流量重新路由到恢复区域。实施失效转移时，使用数据面板操作并避免控制面板操作，如此部分所述：REL11-BP04 恢复期间依赖于数据面板而不是控制面板。

要了解有关此选项及其他选项的更多信息，请参阅灾难恢复白皮书中的此部分。
设计工作负载的失效自动恢复计划。

失效自动恢复是指在灾难事件消除后将工作负载运营恢复到主区域。向主区域预置基础设施和代码通常遵循最初使用的相同步骤，依赖于基础设施即代码和代码部署管道。失效自动恢复面临的挑战是还原数据存储，并确保它们与运行中的恢复区域保持一致。

在失效转移状态下，恢复区域中的数据库处于活动状态，并且具有最新数据。然后，目标是从恢复区域重新同步到主区域，确保主区域处于最新状态。

某些 AWS 服务会自动执行此操作。如果使用 Amazon DynamoDB 全局表，即使主区域中的表不可用，只要重新联机，DynamoDB 就会继续传播任何挂起的写操作。如果使用 Amazon Aurora Global Database 并使用托管的计划失效转移，则维护 Aurora 全局数据库的现有复制拓扑。因此，主区域中以前的读/写实例将成为副本，并从恢复区域接收更新。

如果这不是自动执行的，则需要在主区域中重新建立数据库，作为恢复区域中数据库的副本。在许多情况下，这将涉及删除旧的主数据库，然后创建新的副本。

失效转移后，如果可以继续在恢复区域中运行，请考虑将此区域设为新的主区域。您仍然需要执行上述所有步骤，将以前的主区域变成恢复区域。有些组织会进行定期轮换，定期交换其主区域和恢复区域（例如每三个月一次）。

失效转移和失效自动恢复所需的所有步骤都应保存在行动手册中且可供所有团队成员使用，并定期接受审查。

使用弹性灾难恢复时，服务会协助编排并自动执行失效自动恢复流程。有关更多详细信息，请参阅 Performing a failback。