灾难恢复服务
出于明显的原因，恢复备份数据是备份服务的一项标准功能。 但是，灾难不仅仅限于数据丢失。 阻止组织的服务器（无论是真实的还是虚拟的，无论是本地服务器还是基于云的服务器）可用的中断会对组织产生负面影响，有时甚至是灾难性的影响。 灾难恢复 (DR) 服务的目的不仅是为数据和单个资源提供备份，而且还为整个系统提供备份，以便在这些系统出现故障或脱机时，可以通过将流量重定向到准备使用负载的副本来恢复服务。
灾难恢复是公有云证明其真正目的的地方。 它不仅仅是一个巨大的磁带驱动器。 由于云资源是虚拟的，可以立即复制副本以替换突然消失的资源。 副本甚至可以托管在世界各地，而不仅仅是它们为避免区域范围内出现中断而镜像的系统。 相比之下，维护物理信息系统的物理副本（并尝试在地理位置不同的位置这样做）的代价和云在维护这些系统的连续性方面体现的价值开始变得明显。
主要云提供商提供了灾难恢复即服务 (DRaaS)，但是必须精心计划和配置这些服务，才能提供客户所需的故障转移支持。 因此，我们首先研究影响这种计划的目标和指标。
目标和指标
在灾难事件中，组织及其客户可能无法同时访问多种类别的数字资产，最重要的是：
数据库和数据存储：除了在库存中记录有关客户、商品和/或服务的重要信息之外，还需要维护整个组织的业务交易和流程的活动状态
批量数据：包括文档、媒体文件和其他保存的记录，这些记录是人们使用的应用程序的产品
与人员和业务服务的通信和连接，因此包括可能进行的任何业务活动的实质
应用程序：组织的店面，面向客户和顾客及其自身的利益干系人
尽管灾难恢复是作为一项单一服务提供给客户的，但是这些类别中每个类别的恢复过程都是相互独立的。 在客户端/服务器时代，许多组织在个人计算机上开展日常业务。 如果电脑发生故障，并且电脑的本地存储中存在备份映像，则理论上可以将其恢复到新的电脑上，并且可以继续工作。 首先借助通过 LAN 操作系统和以太网电缆连接的联网电脑，可以从备份映像还原网络中的每台电脑，然后网络本身就可以恢复。
云无法以这种方式工作。 甚至充当组织应用程序的服务器的虚拟机也不会完全封装其工作的任何部分。 备份服务为大容量数据以及在一定程度上为事务数据和数据库提供了安全网。 但是，其中每个实体都是其自己的组件，因此在灾难期间恢复业务功能需要从安全可靠的位置重新建立每个组件的大多数（如果不是全部）功能。
因此，灾难恢复过程要求在采取的每个过程之间进行协调，以使组织恢复正常运作。 此外，由于灾难本身的存在，在此期间开展业务的性质变得更加重要。 能够破坏关键基础结构的事件可能已经破坏了公司的其他功能方面（仓储、发货、制造和交付）。 很可能，正在还原的业务不可能是在灾难事件发生之前顺利恢复的业务。
这些过程共同构成了常见且明确定义的服务级别目标。 来自 AWS 和 Azure 的灾难恢复服务以及基于 Google Cloud 构建的第三方服务可以识别以下内容：
恢复点目标 (RPO) - 根据要视为已恢复的已备份资产，需要将所需的最小数据量传递回该服务的客户端。 相反，可以将此数量看作是可接受的最大数据丢失量，表示为从 100 中减去的百分比。
恢复时间目标 (RTO) - 执行还原过程所允许的最大时间范围，你也可以将其看作衡量组织愿意承受的停机时间量的度量值。
保持期 - 在需要刷新和更换备份集之前，允许保留备份集的最长时间。
RTO 和 RPO 可能被认为是相互平衡的，因此客户可以决定允许更长的恢复时间以获得更高的恢复点。 如果因可用带宽或停机风险而导致客户发生恢复时间问题，则客户可能无法实现较高的 RPO。
在制定灾难恢复策略时，专业风险顾问或业务连续性顾问可能会坚持使用这三个变量。 在大多数业务影响分析 (BIA) 报告中，RTO 和 RPO 居于首位。 它们是顾问评估灾难事件引起的潜在损失的关键变量。 一些顾问使用称为服务级别目标 (SLO) 的聚合变量，尽管实现 SLO 的单一公式尚未出现。 CSP 可以使用风险顾问已经认可和赞赏的术语来指定其服务级别，这使双方可以更轻松地合作，这通常是组织最终选择灾难恢复提供商的方式。
方法和过程
上一课介绍了信息系统恢复的最基本形式，包括相关文件、存储卷和虚拟机映像的备份。 尽管这继续作为灾难恢复服务选项提供，但实际上，它适用于越来越少的组织，这主要是因为不能充分维护 RTO 目标。
专业的灾难恢复服务提供了多种部署和管理方法，其中一些方法涉及灾难事件发生之前的服务维护。 这些方法总结如下。 这三者都基于上一课中讨论的各种备份选项，它们同样适用于所有服务提供商。 希望启用其中某个恢复模式的客户将选择最适合该模式的复制、地理位置和存储类别。
Pilot Light
使用这种方法（图 5），可以为一个完整的备用数据中心留出空间。 在这里，某些核心服务和应用程序以及支持这些服务和应用程序的数据都保存在故障转移群集中，此群集通常可以在触发灾难事件时自动“点亮”。 同时，部署虚拟服务器时，仅具有基本功能即可使虚拟服务器保持活动状态（如果应对其进行调用）。 这些降级的服务器可能配备有电子邮件和 Web 功能，从而可以与客户以及组织内部进行通信。 启用 Pilot Light 恢复模式可能需要连续同步易失性数据存储，例如事务数据库和电子邮件卷。
图 5：Pilot Light 恢复方案的主动和被动组件。
热备用状态
在图 6 所示的这种恢复模式下，所有系统服务和应用程序以及所有关键业务数据的连续运行副本都至少保存在一个单独的地理位置中。 活动路由器将绕过对此完整副本的访问，直到灾难事件触发了将活动网络的地址替换为绕过路由中的地址的规则。
图 6：一种热备用状态恢复方案，其中备用命名空间中的某些组件可以完全运行。
热备用服务器
在这种情况下（图 7），至少有两个所有服务和应用程序的完整副本始终在运行，并且它们之间具有完整和连续的数据同步。 主路由器充当一种大型负载均衡器，将请求按大致相等的比例分发给所有服务器位置。 灾难事件的发生触发了类似于防火墙的过程，其中受影响的系统的地址已从路由表中删除。
图 7：使用热备用服务器，命名空间中通常作为保留、备用空间的所有组件都是活动的、完全可操作的，并可实时处理主数据的副本。
云原生应用程序
从理论上讲，组织可以选择一个提供商的灾难恢复服务作为另一个提供商托管的服务的安全网。 换句话说，如果 IT 人员给予适当的关注，则一个 CSP 的基础结构（例如 Google 的基础结构）可以充当另一个 CSP 的基础结构（例如 Azure 的基础结构）中托管的热备用状态过程的故障转移目标。 出于某些原因，或者如果企业内的计算资源由世界不同地区的不同部门管理，则可能需要这种设置。
目前，本地数据中心以及云中容器化基础结构的存在可能会对所有这些灾难恢复方法产生重大影响。 所谓的云原生应用程序可将功能分布在多个副本容器中，其中一些容器或所有这些容器可以同时运行。这种应用程序专门设计用于公有云平台或与其工作方式类似的平台（例如 Microsoft Azure Stack）。 原因与其说是为了启用新的灾难恢复方案，不如说是为了在处理器之间分配工作负载。
云原生基础结构的另一方面是能够通过网络地址联系其内容已自动复制的数据库，该网络地址的映射是现有应用程序所独有的。 （换句话说，尽管它使用 Internet 协议，但它的地址不在更广泛的公共 Internet 上。）这样，在发生灾难事件时，虽然连接到数据库的某些节点可能会关闭，但许多节点将保留下来，而另一些节点将取代不可用的节点。 尽管可以肯定地将其描述为灾难恢复，但这可能还不符合内置灾难恢复的条件。
灾难恢复即服务 (DRaaS)
对于公有云服务提供商而言，灾难恢复是一种使用其核心备份和数据传输服务的方法。 每个主要的 CSP 都在备份服务之上实现了不同的策略来帮助灾难恢复。
AWS CloudEndure
服务迁移是指将虚拟工作负载从专用本地基础结构迁移到公有云基础结构。 对于在公有云中运行的某些灾难恢复服务而言，此迁移是必需的，以便在灾难事件发生后的几分钟内实现其故障转移和恢复的任务目标。
在 2019 年 1 月，Amazon 收购了专用服务迁移服务 CloudEndure，此服务使用 AWS 作为其基础结构提供商。 自那时起，Amazon 便将 CloudEndure 集成到其主要服务线中，从而免费向 Amazon 客户提供服务迁移。 现在，AWS 将服务迁移作为快速启用温或热备用服务器进程的一种手段。 AWS 不会向客户收取迁移过程的费用，但会针对每个灾难恢复场景所预配的冗余资源收费。 不过，不产生额外的费用使得 CloudEndure 可以立即与大量的第三方灾难恢复服务竞争。
Azure Site Recovery
Microsoft 的灾难恢复服务 Azure Site Recovery 是热备用状态恢复方法的托管部署，适用于基于 VM 的环境和运行 Linux 或 Windows 的物理（本地）服务器。 VM 主动复制到次要区域（图 9.8），只需单击一下按钮即可将故障转移启动到次要区域。 客户每月都需要为受 Azure Site Recovery 保护的每台服务器或 VM 付费（费用当前约为 $25）。
图 8：使用 Azure Site Recovery 实现的故障转移方案。
Google Cloud 灾难恢复
与备份一样，Google 不提供专门用于灾难恢复的品牌服务。 相反，它提供了用于数据存储和数据传输的必要工具和资源，并为客户提供了如何在各种灾难恢复场景中最好地使用这些工具和资源的指南。
由于 Google 提供了 Coldline 存储选项并对其应用了折扣，因此 GCP 适用于各种方案。 对于维护大量大容量数据的组织而言，Coldline 是一个不错的选择。 对于平均大小为数十 GB 的媒体文件，旋转磁盘已成为不切实际的容器。 网络附加存储 (NAS) 组件仅在本地级别为媒体创作组织提供可访问性和可管理性解决方案。 它们具有内部冗余，但不具有防灾能力。 而且，像上述三种方案中的任何一种方案一样，灾难恢复方案对于此类客户都不可行（甚至无法负担）。 Coldline 为此类客户提供了至少一种可行的方式，以实现名义上的业务连续性保障级别。