什么是灾难恢复？

灾难恢复 (DR) 是企业各个业务部门制定和维护的总体业务连续性计划的一部分。一个行之有效的灾难恢复计划可降低关键任务系统和关键业务系统计划外停机（甚至计划内停机）对企业运营和持续营收能力的影响。

而要想实现这一目标，DR 计划应提供一个灵活的体系，助力企业统一运营、增强协作，进而快速改造和恢复系统运行，构建更具弹性的基础设施。

灾难恢复为何重要？

如果企业的薪资系统经常在算薪和发放工资时出现故障，企业能持续运营多长时间？如果延迟缴纳联邦税、州税和地方税，企业会受到哪些处罚？如果无法按时发放薪资，企业会面临哪些后果？员工还会继续待在企业多久？

是否要实施灾难恢复计划？这已经不再是一个问题了。真正的问题是当丢失几分钟、几天或几周的重要数据时，当多年来建立的信任瞬间毁于一旦时，企业会付出什么样的代价？

如今，企业都希望快速响应破坏性事件，确保持续运营。在这一背景下，灾难恢复不应再只是一种事后补救措施，一种只有预算充足时才能享有的“奢侈品”。相比实施一个弹性计划的成本，企业更应深入评估弹性计划缺失可能带来的损失，例如无法满足服务级别协议 (SLA) 或中断导致的处罚和收入损失。一边是 DR 实施成本，一边是罚金、收入损失和失去客户信任，如何选择已经非常明确了。

图片标题：收入、生产力和忠诚度损失。图片展示了三个关键统计数据。这些数据来自 IBM 委托 Forrester Consulting 于 2019 年进行的一项研究。在研究中，Forrester Consulting 针对“计划内和计划外停机给您的企业带来了哪些损失？”这一问题进行了广泛调研。
左栏的统计数据显示，53% 的受访者回答“收入损失”。中间一栏的统计数据显示，47% 的人回答“生产力损失”。右栏的统计数据显示，41% 的受访者回答“品牌权益或信任损失”。

计划外停机

面对自然灾害、IT 运营人员/服务提供商错误、数据损坏和勒索软件攻击而导致的停机，企业必须确保业务连续运营，以此避免发生灾难性损失、被投机取巧的竞争对手取代或品牌声誉受损。

这些后果看似夸张，但它们的确是很多知名企业近年来的血泪教训 — 未能及时恢复数据导致大量的关键事务数据和客户信息丢失，从而失去客户信任。

现实中，导致业务运营中断的场景和根因数不胜数。

图片标题：计划外停机的主要原因。图片中的柱状图展示了造成计划外停机的几种主要原因。这些原因可分为三类：操作故障、自然灾害和人为事件。在图片中，左、中、右三部分分别代表操作故障、自然灾害和人为事件。该图片来自 Forrester Research, Inc。

计划内停机

云端的灾难恢复即服务 (DRaaS) 可为企业提供高度的运营灵活性。现实中，相比灾难性事件恢复，企业更多是使用灾难恢复解决方案应对计划内停机。

典型痛点

• 传统灾难恢复方法需要企业投资部署自动化技术。
• 即便是 Tier 1 数据中心内的业务系统也可能频繁受到断电事件影响。在您的企业中，断电等常见事件造成一两天生产力损失的频率是多少？当发生此类事件时，IT 人员需要花费数小时或数天的时间召开电话会议，使用临时解决方案来启动和恢复系统运行。 • 某些企业投入大量 IT 预算开发自动化解决方案来进行灾难恢复，然而却对其信心不足，甚至要定期测试，确保其能够持续按预期运行。 • 基于计划内维护窗口的恢复作业通常要耗费一天或数天时间。 • 即便拥有周密的 DR 计划或运行手册，系统恢复也可能耗费数天时间，且系统能否恢复严重依赖 IT 运营人员。

灾难恢复的主要目标

灾难恢复有两个主要目标，一是尽快将受影响的系统恢复到运行状态，二是在发生灾难性事件或计划内停机后尽可能减少数据丢失。这两个主要目标的衡量指标分别被称为恢复时间目标 (RTO) 和恢复点目标 (RPO)。

现实中，不同业务系统对这两个指标的要求各不相同，具体取决于 IT 运营与企业主之间的服务级别协议。

图片标题：数据保护术语。图片中的反向延长线表示数据丢失容差和停机时间容差。左侧是“数据丢失”，右侧是“停机时间”。

恢复时间目标

恢复时间目标是指在发生计划内或计划外停机后，将业务系统恢复到完全运行状态所需的时间。

恢复点目标

恢复点目标是指任何特定业务遭受重大损害前可能丢失的最大数据量。它通常表示为距离上次数据备份、复制或快照的增量时间。

灾难恢复与高可用性对比

一般来说，高可用性 (HA) 旨在防范单点故障，灾难恢复旨在防范多点故障。在云计算中，得益于高可用性和容错域，物理基础设施（包括电源、散热、存储、网络和物理服务器）层面的单点故障保护完整融入了整体架构。

高可用性可提供高度的可扩展性和弹性，能够有效防止数据丢失或处理性能损耗。如今，几乎所有企业级云技术提供商的产品都采用了高可用性架构。

然而，当涉及到复杂的数据映射和复制技术时，旨在为数据库提供零数据丢失和零停机保护的高可用性灾难恢复解决方案不仅成本非常高，而且无法通过完全备份、时间点恢复点目标和不可变存储防范勒索软件攻击。

对此，企业可结合使用传统 HA 解决方案与低成本的 DR (CDR) 云技术解决方案。CDR 技术可为需要通过长期增量回滚实现零数据丢失、零停机 HA 以及勒索软件攻击保护的数据库提供额外保护。

相比之下，本地部署 DR 解决方案需要在源位置和固定目标数据中心位置复制 IT 基础设施，成本高昂，灵活度低。它无法基于 WAN 运行，无法在不同环境之间迁移服务器，因此需要在源数据中心和目标数据中心之间建立一个专用线路 — 就像构建一个独立的互连 LAN 环境那样。传统 DR 还无法在异构环境（例如本地部署环境与云技术平台）之间或两个不同的云技术平台之间迁移服务器。

同时，DRaaS 使用供应商提供的备份解决方案和开源迁移工具创建严格受控、高度特定的环境，最终用户只能从 VMware 本地部署环境中恢复 DRaaS 提供商传统托管环境中的工作负载。问题在于，这些供应商的解决方案同样可能成本高昂，只能保护有限的工作负载，只支持有限的计算环境。

DR 工作流、运行手册和计划

Oracle 通常将 DR 工作流称为 DR 计划。DR 计划（或运行手册）将记录所有预定义的，用于将计算实例、平台、数据库和应用迁移到预定恢复区域的步骤和任务，包括在灾难恢复操作（如故障切换或故障转移）期间需要手动或在某种程度上自动执行的所有任务或步骤。实践中，“DR 计划”、“DR 运行手册”和“DR 工作流”这三个术语可互换使用。

DR 操作（故障切换与故障转移）

DR 操作是指执行 DR 计划中每个预定义步骤或任务，将基础设施、数据库和应用恢复到完全运行状态的过程。对此，我们通常使用两个术语来描述“将应用体系迁移到其他位置”，分别是故障转移和故障切换。

故障转移

故障转移多用于应用、数据库和虚拟机崩溃，所有资源（包括存储、数据和来宾操作系统）处于不一致状态的计划外停机场景。在这种场景下，主用区域完全不可访问和不可用，企业需要触发真正的灾难恢复操作。

这时，DR 计划中的所有灾难恢复任务只能在备用区域中执行，故而云技术提供商的 DRaaS 解决方案必须在备用区域中采用高可用性设计，确保发生灾难性事件时备用区域可访问且可正常运行。

故障切换

故障切换则多用于计划内停机场景，包括应用、数据库以及虚拟机或服务器的有序停机。在这种场景下，主用区域和备用区域都能正常运行，IT 运营人员可以将一个或多个系统从一个区域“切换”到另一个区域，进行维护或执行滚动升级。

云端部署策略

现代企业可按照自己的需求，综合成本、性能和业务连续性等因素选择以下一种或多种部署模式。如今，随着企业持续将业务迁移到云端，对可靠的部署策略的需求正越来越普遍。

跨区域 DR 解决方案

跨区域 DR 解决方案可保护企业不受完全中断影响，能够确保企业持续访问托管在单一提供商的云基础设施中的业务系统。所谓跨区域 DR，意味着企业能够按需将任何业务系统的整个应用体系（包括虚拟机、数据库和应用）切换到位于其他位置的另一个区域。

一个良好的 DRaaS 解决方案应支持企业将整个企业系统（如人力资源门户、财务服务门户或企业资源管理应用）切换到另一个区域，应能够满足每个应用的服务级别协议规定的恢复时间目标和恢复点目标。

使用跨区域灾难恢复解决方案（如 Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery），企业可在发生灾难性事件时确保所有应用正常访问整个区域，包括区域中所有的可用性域。

混合云技术灾难恢复解决方案

混合云技术灾难恢复是一种主流解决方案，支持企业将工作负载和虚拟机从自有数据中心切换到云基础设施。实践中，它通常被用作灾难恢复解决方案来保护数据以及企业关键业务系统的可用性。

Oracle 为客户提供的混合云技术解决方案是 OCI 与物理服务器、Oracle Cloud Appliance 或企业物理数据中心中其他系统的松散联盟。Oracle Private Cloud Appliance X9-2 和 Oracle Exadata Cloud@Customer 等 Oracle Cloud Appliance 便是本地部署系统与 OCI 集成的优秀范例。

Oracle 合作伙伴提供的某些产品（如 Rackware）也可用于在本地部署基础设施与 OCI 之间实施灾难恢复。您可以通过 Oracle Cloud Marketplace 获取 Rackware。

多云灾难恢复解决方案

所谓多云灾难恢复解决方案，指的是通过在两个或两个以上提供商的云基础设施中托管应用体系的各个组件来保护应用和数据。Oracle 与 Microsoft Azure 的合作便是多云关系的一个优秀范例。

理想的灾难恢复即服务应当全面支持跨区域灾难恢复、混合云灾难恢复和多云灾难恢复。在这方面，OCI 的 DRaaS 支持跨区域灾难恢复和混合云灾难恢复。

面向数据库的数据一致性

针对数据库的灾难恢复解决方案应通过适当的方法确保数据一致性。所谓恢复点目标，定义的就是可将数据库（包括进行中的事务）恢复到数据完全一致状态的时间点。

对于无服务器或平面文件数据库，数据一致性问题不大。但对于复杂的关系数据库（如 Oracle Database 或 MySQL），恢复到特定时间点的数据一致状态非常重要，同时也非常复杂。

MySQL 数据库的灾难恢复注意事项

当在 OCI 上运行 MySQL Database Service 时，MySQL 数据库系统可看做是一个面向一个或多个 MySQL 实例的逻辑容器。它会提供一个界面来帮助用户进行任务管理，例如供应、自动备份和时间点恢复等等。

用户可使用 MySQL 二进制日志和本机复制技术执行时间点恢复、高可用性和灾难恢复任务；使用 MySQL 组复制来创建本地容错集群，提高可用性；使用 MySQL 异步复制技术执行地理分布式灾难恢复。

一个高可用的数据库系统支持在不同的可用性域或容错域中部署三个 MySQL 实例。一旦某个实例发生故障，系统将切换至另一个实例，确保零数据丢失并尽可能降低停机时间。对于跨区域的灾难恢复，系统还可以在两个数据库系统之间创建入站复制通道。

请点击以下链接，详细了解云端 MySQL 灾难恢复。

• MySQL 业务连续性概述
• MySQL 高可用性概述
• MySQL 入站复制概述

Oracle 数据库灾难恢复注意事项

Oracle Maximum Availability Architecture (MAA) 为 Oracle 数据库提供架构、配置和生命周期优秀实践，可确保本地、云端或混合配置中的数据库满足高可用性服务级别要求。

请点击以下链接，详细了解面向云端灾难恢复的 Oracle Maximum Availability Architecture。

• Oracle Maximum Availability Architecture 落地页
• Oracle Maximum Availability Architecture 参考架构
• Oracle Maximum Availability Architecture 之 Oracle Fusion Middleware 优秀实践
• Oracle Maximum Availability Architecture 之 应用优秀实践

基于云技术的部署架构

部署架构将定义如何在区域之间部署各种组件（如计算、平台/数据库和应用），创建弹性、针对数据库完全故障的恢复方法；将定义应用套件正常运行期间所有要素的所在位置，以及需要在备用区域中恢复哪些要素才能使数据库恢复运行。

Oracle 认为，一个理想的 DRaaS 解决方案应当具有足够的灵活性来适应 DR 部署架构的任意组合，满足不同业务系统各自的服务级别要求；同时，云技术提供商应支持客户自由选择“上述所有”解决方案，满足企业的各种业务系统的 SLA 要求。

关于 DR 策略和部署架构的术语有很多。它们（包括模式和方法）分别描述了如何部署基础设施、平台和应用来进行灾难恢复，总体上可分为两类：主动/主动、主动/备用。

以下是这两种 DR 策略下各种部署架构的通用术语。

策略	部署架构	RPO	RTO
主动/备用	冷备用	小时	小时
主动/备用	试点指示灯	分钟	小时
主动/备用	温备用	秒	小时
主动/备用	热备用	秒	分钟
主动/主动	主动/主动	接近于零	接近于零

本节将介绍关于主动/主动和主动/备用灾难恢复方法的一些变体。企业可按需选择，无论哪一种，都可以实现业务连续性。

主动/备用部署架构

主动/备用部署架构拥有多种变体。它有时也被称为主动/被动部署，通常可分为试点指示灯、冷备用、温备用和热备用 4 种架构。

这 4 种架构本质上是一样的，都是将整个应用体系 (100%) 部署在主用区域，同时在备用区域运行与主用区域相一致，但不完全相同（低于 100%）的业务系统。

在以下章节中，您可以通过概念图直观了解各种常见主动/备用部署架构之间的差异。注意：这些概念图未展示如何为应用体系实施灾难恢复，不宜被视为参考架构。

冷备用

在这一方案下，任何时候虚拟机 (VM)、数据库和应用都仅存在于当前的主用区域中，文件和块存储卷组（包含各个 VM 的启动磁盘和所有其他虚拟磁盘）则被复制到备用区域。

图片左侧为主用区域，右侧为备用区域。其中，主用区域分为三个部分：应用、数据库和基础设施 — 各部分分别通过各自的图标表示。两个区域顶部分别都有一个负载均衡器图标，但备用区域中的负载均衡器图标相对颜色更浅。备用区域同样分为三个部分：应用、数据库和基础设施。在备用区域中，仅基础设施块部分拥有图标，分别代表对象存储、块存储和文件存储；数据库和应用部分为空。两个区域的基础设施之间的两个箭头分别代表对象存储复制和存储复制，复制方向为从主用区域复制到备用区域。

在执行 DR 操作（如故障切换或故障转移）期间，备用区域中的复制存储将被激活，其中的 VM 将从主动区域 VM 发生停机或故障的时间点启动。备用区域 VM 与主动区域 VM 完全相同。

这种部署架构具有多重优势，例如部署成本低、维护开销低、运营成本低。但是，它不太适合使用关系数据库作为后端，需要定期执行冷备份来确保数据一致性的应用，更适合可容忍偶尔、短时间完全中断的应用。

实践中，大多数 IT 运营人员会通过定期关闭数据库、创建块存储快照，然后恢复数据库正常运行来解决这一问题。这一操作相当于定义一个恢复点目标，因为只能恢复到备份完成的时间点。

这一架构虽然恢复时间较长、数据丢失风险较大，但对某些工作负载来说不失为一种可行的解决方案。例如，对于基于平面文件数据库、无服务器数据库或根本不需要数据库的应用，或只想跨区域切换一组虚拟机以提高灵活性的客户而言，这一架构可称得上是最佳之选。

DR 工作流示例示例

我们通过以下两个场景向您展示冷备用部署架构的 DR 操作流程。

在故障切换场景下，主用、备用区域都执行以下操作：

• 主用应用暂停运行。
• 主用数据库暂停运行，并同步到备用区域。
• 主用虚拟机有序地暂停运行。
• 主用存储同步到备用区域。
• 将复制存储联机，执行反向复制 — 备用区域中的存储转换为主用。
• 启用主用虚拟机位于备用区域的复制副本，启动应用体系所需的所有系统应用或工具 — 备用区域中的系统应用和工具转换为主用。
• 在备用区域中使用复制存储中最新的冷备份或事务以及重做日志，恢复主用数据库的复制副本。
• 启用和挂载主用数据库的复制副本 — 备用区域中的复制副本转换为主用。
• 启用和验证主用应用的复制副本 — 备用区域中的复制副本转换为主用。
• 对 DNS 和负载均衡器执行所有必要的变更，确保可通过公共网络访问应用。

在故障转移场景下，仅备用区域执行以下任务：

• 将复制存储联机，执行反向复制 — 备用区域中的存储转换为主用。
• 启用主用虚拟机位于备用区域的复制副本，启动应用体系所需的所有系统应用或工具 — 备用区域中的系统应用和工具转换为主用。
• 在备用区域中使用复制存储中最新的冷备份或事务以及重做日志，恢复主用数据库的复制副本。
• 启用和挂载主用数据库的复制副本 — 备用区域中的复制副本转换为主用。
• 启用和验证主用应用的复制副本 — 备用区域中的复制副本转换为主用。
• 对 DNS 和负载均衡器执行所有必要的变更，确保可通过公共网络访问应用。

温备用

在这一方案下，主备区域均部署虚拟机，但两个区域中的虚拟机之间完全独立且各自拥有唯一的主机名和预分配的 IP 地址。客户可以自行决定是否运行备用区域中的虚拟机。

图片左侧为主用区域，右侧为备用区域。其中，主用区域分为三个部分：应用、数据库和基础设施 — 各部分分别通过相应的图标表示。两个区域顶部分别都有一个负载均衡器图标，但备用区域中的负载均衡器图标相对颜色更浅。备用区域同样分为三个部分：应用、数据库和基础设施。在备用区域中，基础设施块部分有 3 个图标，分别代表对象存储、块存储和文件存储，另外还有一个图标代表虚拟机，但颜色较浅。备用区域中的数据库图标和应用图标的颜色也相对较浅。两个区域的基础设施之间的两个箭头分别代表对象存储复制和存储复制，复制方向为从主用区域复制到备用区域。

主备区域中的数据库均处于运行状态。

对于 Oracle 数据库，我们建议使用 Oracle Data Guard 来复制主用和备用数据库。更多详细信息，请参阅 Gold MAA 参考架构。

对于非 Oracle 数据库，请使用相应提供商的本机复制技术，在主备区域之间进行数据库同步。

与主用区域一样，备用区域中也部署应用，但应用不能运行或访问。

DR 工作流示例示例

我们通过以下两个场景向您展示温备用部署的 DR 操作流程。

在故障切换场景下，主用、备用区域都执行以下操作：

• 主用应用暂停运行。
• 主用数据库暂停运行，并同步到备用区域。
• 主用虚拟机有序地暂停运行。
• 主用存储同步到备用区域。
• 将复制存储联机，执行反向复制 — 备用区域中的存储转换为主用。
• 如果备用虚拟机尚未运行，启用该虚拟机。应用体系所需的所有系统应用或工具也将启用 — 备用区域中的系统应用和工具转换为主用。
• 备用数据库被切换为完全读/写访问权限，备用区域中的数据库转换为主用。
• 启用和验证备用应用，备用区域中的应用转换为主用。
• 对 DNS 和负载均衡器执行所有必要的变更，确保可通过公共网络访问应用。

在故障转移场景下，仅备用区域执行以下任务：

• 将复制存储联机，如果可能，执行反向复制 — 备用区域中的存储转换为主用。
• 如果备用虚拟机尚未运行，启用该虚拟机。应用体系所需的所有系统应用或工具也将启用 — 备用区域中的系统应用和工具转换为主用。
• 使用复制存储中的最新事务和重做日志恢复备用数据库。
• 备用数据库被切换为完全读/写访问权限，备用区域中的数据库转换为主用。
• 启用和验证备用应用，备用区域中的应用转换为主用。
• 对 DNS 和负载均衡器执行所有必要的变更，确保可通过公共网络访问应用。

热备用

在这一方案下，主备区域均部署并运行虚拟机，但这些虚拟机相互之间完全独立且各自拥有唯一主机名和预分配的 IP 地址。

图片左侧为主用区域，右侧为备用区域。其中，主用区域分为三个部分：应用、数据库和基础设施 — 各部分分别通过相应的图标表示。两个区域顶部分别都有一个负载均衡器图标，但备用区域中的负载均衡器图标相对颜色更浅。备用区域同样分为三个部分：应用、数据库和基础设施。主备区域的应用、数据库和基础设施部分均拥有图标，基础设施部分均拥有虚拟机、文件存储、对象存储和块存储图标，但仅备用区域中的数据库图标颜色较浅。两个区域的基础设施之间的两个箭头分别代表对象存储复制和存储复制，复制方向为从主用区域复制到备用区域。

主备区域中的数据库均处于运行状态。

对于 Oracle 数据库，我们建议使用 Oracle Data Guard 来复制主用和备用数据库。更多详细信息，请参阅 Gold MAA 参考架构。

对于非 Oracle 数据库，请使用相应提供商的本机复制技术，在主备区域之间进行数据库同步。

备用区域中应用处于运行状态，但无法通过公共网络访问。

DR 工作流示例示例

我们通过以下两个场景向您展示热备用部署的 DR 操作流程。

在故障切换场景下，主用、备用区域都执行以下操作：

• 主用应用暂停运行。
• 主用数据库暂停运行，并同步到备用区域。
• 主用虚拟机有序地暂停运行。
• 主用存储同步到备用区域。
• 将复制存储联机，执行反向复制 — 备用区域中的存储转换为主用。
• 备用虚拟机始终保持运行，启动应用体系所需的所有系统应用或工具 — 备用区域中的系统应用和工具转换为主用。
• 备用数据库被切换为完全读/写访问权限，备用区域中的数据库转换为主用。
• 启用和验证备用应用，备用区域中的应用转换为主用。
• 对 DNS 和负载均衡器执行所有必要的变更，确保可通过公共网络访问应用。

在故障转移场景下，仅备用区域执行以下任务：

• 将复制存储联机，如果可能，执行反向复制 — 备用区域中的存储转换为主用。
• 如果备用虚拟机尚未运行，启用该虚拟机。应用体系所需的所有系统应用或工具也将启用 — 备用区域中的系统应用和工具转换为主用。
• 使用复制存储中的最新事务和重做日志恢复备用数据库。
• 备用数据库被切换为完全读/写访问权限，备用区域中的数据库转换为主用。
• 启用和验证备用应用，备用区域中的应用转换为主用。
• 对 DNS 和负载均衡器执行所有必要的变更，确保可通过公共网络访问应用。

主动/主动部署架构

在这一方案下，主备区域均拥有功能齐全的完整应用体系，同时处理工作负载。

图片左侧为主用区域，右侧为备用区域。主备区域均分为三个部分：应用、数据库和基础设施，每个区域都拥有各自的图标。两个区域顶部分别都有一个负载均衡器图标，两个图标都不是浅色图标。主备区域中的应用、数据库和基础设施部分的图标均为深色。两个基础设施块之间的箭头代表存储复制（可选），表示从主用区域向备用区域复制。

主备区域中的数据库均处于运行状态。

对于 Oracle 数据库，我们建议使用 Oracle GoldenGate 来进行主动/主动应用配置。此外，我们还建议对每个区域中的本地备用数据库使用 Oracle Data Guard，以实现近乎为零的 RTO 和 RPO。更多详细信息，请参阅platinum MAA 参考架构。

对于非 Oracle 数据库，请使用相应提供商的本机复制和主动/主动技术在主备区域之间保持数据库同步。

备用区域中的应用处于运行状态且始终运行工作负载，可通过公共网络访问。

使用 DRaaS 自动执行灾难恢复任务

Oracle 团队投入大量心血在产品（包括 Oracle 绝大多数企业级数据库和应用）中置入了高可用性，设计出了丰富的优秀实践和部署架构来帮助企业在传统本地部署环境和云端环境中进行灾难恢复。其中，每个产品线均针对该应用提供了独特的 DR 方法，包含通过松散耦合的步骤来恢复应用所需的所有组件。

基于云技术的灾难恢复即服务将开发人员、云技术架构师和产品解决方案架构师设计的所有松散耦合的步骤整合到了一个可一键启动的无缝工作流中。而 OCI Full Stack Disaster Recovery DRaaS 解决方案具备尤为出色的灵活性、可伸缩性和可扩展性。

使用 OCI Full Stack Disaster Recovery，企业只需点击一下，即可轻松跨全球任意 OCI 区域切换基础设施、数据库和应用。整个过程中，企业无需重新设计或重新部署现有基础设施、数据库或应用即可部署灾难恢复环境，也无需使用专门的管理或转换服务器。

• 详细了解 OCI Full Stack Disaster Recovery
• 详细了解 OCI 的灾难恢复