1 灾难恢复介绍
从根本上说，企业灾难恢复 (Disaster Recovery, DR) 的最佳做法包括设计和实施可以抵御灾难（“业务连续性”）并恢复正常运行（“业务恢复”）的容错硬件和软件系统，同时干预最少，理想情况下没有数据丢失。构建容错环境来实现企业 DR 目标并满足实际预算约束可能成本高昂而且耗费大量时间，并且需要企业强有力的承诺。
DR 规划通常可以应对下面一种或多种类型的灾难：
-
由于自然灾害（地震、风暴、洪水等）或其他原因（火灾、故意破坏、盗窃等）导致的大面积或广泛性 IT 设备损坏。
-
广泛失去 IT 设备关键服务，例如断电、无法进行冷却或网络访问。
-
失去关键人员。
DR 规划过程首先是确定业务必须抵御并从其恢复运行的灾难类型并描述其特征。规划过程要确定高层面的业务连续性 (business continuance, BC) 和业务恢复 (business resumption, BR) 要求，包括必需的容错程度。DR 规划的产物是一个恢复体系结构，使容错系统、应用程序和数据能够在既定的约束下满足这些要求。典型的 DR 约束包括恢复时间目标 (recovery time objective, RTO)、恢复点目标 (recovery point objective, RPO) 和可用预算。DR 体系结构加上业务约束使得 DR 过程以真正的“端到端”方式集成所有系统元素，以保证整个 DR 过程产生可预测的结果。
容错系统通常通过冗余实现稳健性和弹性。全冗余系统构建成本非常高昂，这种系统的体系结构中不会发生单点故障，可以在其限度内可能最严重的灾难发生期间运行并从灾难中恢复运行。航天飞机和航空飞机控制系统就是很好的全冗余系统的例子。不太关键的 IT 应用程序通常使用冗余较低的不太强大的系统。这些系统构建成本较低，灾难过后必然会引发服务中断，在中断期间，企业将努力复原可恢复的系统、应用程序和数据。
最后，企业的性质、客户的要求和 DR 的可用预算是构想 DR 要求的关键因素。全面的 DR 解决方案可能成本非常高昂，但是不得不构建。您不能让资金、硬件和软件面临潜在的灾难，盼望着抵御灾难并恢复业务运营。不过，如果您明智地规划和构建，可能不得不遭受更长时间的中断、服务降级或两者，直到全部服务可以恢复，但是您仍然可以拥有一个可靠的有限 DR 解决方案。
然而要明白，或许再多的规划也不能预料和应对全部可能的 DR 情形。例如，起初一个系统上有一个显然微不足道的问题，该问题可能会随着时间的推移蔓延进而以不同方式影响其他系统，全部加起来造成了没有恢复情形的灾难。同样，如果关键的假设不成立（例如，如果关键部件或服务不可用，或者如果 DR 提供商的交付能力不像宣传的那样强大），企业履行服务协议的能力可能会变差。不过，真正的关键在于，如果发生的灾难超过您规划的最严重的情形，可能无法进行恢复。
定义恢复时间目标 (Recovery Time Objective, RTO)
RTO 是一个服务级别目标，是指在灾难发生后达到所需运行能力所需的时间。例如，业务要求可能规定这样的 RTO：所有生产系统在将会持续超过一个小时的任何计划外中断发生后的 30 分钟内启动并以灾难前能力的 80% 运行（如果不存在 DR 能力）。发生灾难后 RPO 的处理时间、是否有合格的 IT 人员以及所需手动 IT 流程的复杂性就是可能会使 RTO 确定成形的约束的例子。RTO 不适用于全容错系统，因为这些系统在灾难期间和灾难过后隐式恢复，不会造成服务中断。
DR 规划者可能会根据定义的部分或全部 BC 要求设置不同的 RTO。不同类型的业务运营可能需要不同的 RTO，例如联机系统与批处理窗口需要不同的 RTO。进一步说，可能会在一个分阶段 DR 规划的各个阶段应用不同的 RTO，其中每个阶段都有一个定义的 RTO。更进一步说，对于可恢复的应用程序，各个服务级别中的每一个级别可能有不同的 RTO。
BC 数据可用性要求对于 RTO 规划极其重要。当灾难恢复站点中不存在必须输入 DR 恢复过程的数据时，现场检索这些数据所需的时间将会延迟 RTO。例如，位于异地保管库中的数据需要一些时间来检索。如果开始灾难恢复操作之前在恢复站点复制了最新的输入数据，恢复便可快速进行。
定义恢复点目标 (Recovery Point Objective, RPO)
RPO 是一个业务连续性目标，规定灾难恢复过程复原所有可恢复系统后达到的业务状态或业务状况。从概念上讲，RPO 是灾难发生前的已知“回滚”或同步目标状态。也就是说，RPO 是中断的可恢复应用程序可从其恢复处理的灾难恢复后的点。在 RPO 与发生灾难的时间之间的间隔内发生的所有事务都不可恢复。RPO 不适用于全容错系统，因为灾难并不影响这些系统的业务连续性。
图 1-1 通过建议多个恢复点供 DR 规划者考虑来阐明 RPO 的概念。规划必须确保所需的 RPO 相对于选择的 RTO 可行，反之亦然。一般来说，与比较远的 RPO 相比，要求 RPO 比较接近灾难发生时间的灾难恢复规划需要更高的容错并且实施成本更高。与 RTO 一样，DR 规划者可能会根据不同的 BC 要求、DR 规划阶段或应用程序服务级别设置不同的 RPO。
更广泛地说，RPO 规划必须确定要复原每个可恢复系统而必须存在的所有支持元素，包括数据、元数据、应用程序、平台、设备和人员。规划还必须确保这些元素在所需的业务状况级别可用以实现恢复。BC 数据状况要求对于 RPO 规划尤为重要。例如，如果 BC 要求规定了一小时的 RPO，则输入恢复过程的任何数据或元数据都必须在 RPO 之前保持最新，否则将无法实现 RPO。组织的 DR 过程将指定在规定的 RTO 内实现定义的所有 RPO 的步骤。
RPO 恢复需要的系统元数据包括 OS 目录结构和磁带管理系统信息。这些项目必须在灾难恢复过程中进行更新才能启用选择的所有 RPO。例如，要确保 DR 恢复过程的各种元数据输入之间的一致性，必须为将在 RPO 时重新创建的现有数据集取消目录编制；必须将在 RPO 与灾难发生时间之间更新的数据集恢复到 RPO 时或之前存在的版本；必须将与磁带相关的任何目录更改与磁带管理系统同步。
处理临时中断
对于会使生产站点长期不可使用的很长时间的中断，灾难恢复提供了补救措施。虽然本章剩余部分讲解灾难恢复做法，但是制定过程来减轻相对较短的中断（如果任其发展，可能会对生产造成负面影响）可能同样重要。例如，考虑一下这样的服务中断：某些硬件或网络设备在一两个小时内不可用，但是通过一些快速的临时调整，此中断期间可以在“降级模式”下继续生产。临时中断过程将记录如何隔离问题、做出哪些更改、通知哪些人员以及在恢复服务后如何恢复到正常的操作环境。
关键概念：同步点恢复
在定义的 RPO 重新启动生产应用程序是在真正的灾难恢复期间和 DR 测试期间执行的关键操作。最具弹性的 DR 环境将确保每个可恢复的应用程序（无论是来源于他处还是企业内部开发）都实施核心 DR 要求：也就是说，将应用程序设计成从计划的时间点（称为同步点）重新启动，以减轻应用程序执行期间计划外中断产生的影响。在同步点重新启动中断的应用程序时，结果就像应用程序未曾中断一样。
可恢复应用程序的重新启动过程取决于应用程序及其输入的性质。很多时候，真正的灾难恢复或 DR 测试期间的应用程序重新启动过程与正常生产运行期间发生故障时用于重新启动应用程序的过程一样。在可能的情况下，在真正的灾难恢复或 DR 测试期间重用生产重新启动过程可以简化 DR 过程的创建和维护，并利用这些久经验证的过程。在最简单的情况下，一个可恢复的应用程序是只有一个同步点的单个作业步骤，该同步点是该步骤调用的程序的开端。在这种情况下，恢复过程可能像重新提交中断的作业那样简单。再稍微复杂的重新启动过程可能涉及取消应用程序在上次运行期间生成的所有输出数据集的目录编制，然后重新启动应用程序。
如果应用程序具有多个可供选择的内部同步点，其重新启动过程可能并不那么简单。使用检查点/重新启动技术实施这些同步点的应用程序定期记录其进度，例如可以使用记录的检查点信息在中断之前记录的最后一个内部同步点重新启动。重新启动过程将符合每个同步点的要求。如果正在使用检查点，当检查点对应用程序恢复仍然有效时，与检查点关联的数据集不能过期、已取消目录编制或暂存。要为修改其现有输入数据集的作业步骤建立同步点，一种简单的方法是在运行该步骤之前为每个可修改的数据集创建备份副本。通过在 DD 语句中或在动态分配请求中搜索 JCL 属性 DISP=MOD 可以轻松识别这些可修改的输入数据集。如果一个作业步骤失败或中断，只需丢弃所有修改的输入数据集、从备份副本恢复这些输入数据集，并从恢复的副本重新启动该步骤。这些备份副本对于重新启动失败或中断的作业步骤（原数据已过期、已取消目录编制或暂存）也很有用。
将 RPO 与同步点恢复联系起来
当 RPO 与某个同步点保持一致时，执行为该同步点制定的应用程序重新启动过程将从该起点恢复应用程序，就像未发生中断一样（图 1-2）。在该 RPO 后直到发生灾难时处理的所有事务都假定为不可恢复。
在其他时候，BC 要求可能证明将 RPO 置于同步点之间是合理的。在这些情况下，同步点之间的恢复依赖于描述任何关键应用程序状态更改或建立最新同步点后所发生事件的补充数据。例如，考虑一下灾难发生前一分钟的 RPO。假设将一个可恢复的应用程序设计成使用检查点记录其进度，但是假设无法承受在一分钟的时间间隔内创建这些检查点的开销。一个解决方案是降低创建检查点的频率并记录在检查点之间提交的所有事务。该事务日志随后将成为检查点恢复过程用于从最新同步点之后的某个 RPO 重新启动的补充输入数据。在此示例中，应用程序重新启动过程将访问最新的检查点数据并应用补充事务日志来复原在检查点之后且在 RPO 之前处理的所有已提交事务（图 1-3）。这样一来，同步点恢复便可使用来自多个来源的输入数据实现目标 RPO。在 RPO 后直到发生灾难时处理的所有事务都假定为不可恢复。
规划数据高可用性 (Data High Availability, D-HA)
数据通常是企业拥有的最宝贵的资产之一。许多公司格外注重并进行额外的投资来预防业务关键型数据丢失，并确保数据在需要时可用于预期目的。如果一家公司无法应付关键数据丢失，很有可能要遭受灾难性的后果。防止数据丢失最常见的方法或许就是将关键数据的副本存储在不同的存储介质或子系统上，并将其中某些副本存储在不同的物理位置。存储在可移除存储介质（包括盒式磁带、CD-ROM 和 DVD）上的副本通常保管在异地存储位置。通常还会在 IT 设备现场存储额外的副本，应用程序可以在 IT 设备中处理该数据。创建和存储关键数据副本可以提高数据冗余并改进数据容错。对于可移除介质，尤其是对于盒式磁带来说，仅仅提高数据冗余通常不足以确保数据对于将要使用它的应用程序而言也具有高可用性。例如，Oracle 的大型机虚拟磁带 VSM 系统将数据存储在称为 MVC 的物理磁带卷上。VSM 可以自动创建 MVC 副本以改进数据冗余并降低由于介质故障或错放盒式磁带而引起的风险。生产 VSM 系统利用多个专门的硬件组件来检索存储在 MVC 上的数据，包括 VTSS 缓冲区设备、自动化磁带库和磁带库连接的磁带机（称为 RTD，它们也连接到 VTSS 缓冲区设备）。主机应用程序依靠所有这些 VSM 组件一起运行来从 MVC 中检索数据。尽管大多数人不会将单个组件故障视为与在地震中失去整个数据中心同样严重的灾难，但是如果单个 VSM 关键组件在没有备份的情况下发生故障，无论存在多少个冗余 MVC 副本，当然可能会无法检索任何 MVC 数据。因此，虽然创建 MVC 副本是减轻漏洞和风险的久经验证的最佳做法，但并不总是足以保证在发生故障时具备数据高可用性 (data high availability, D-HA)。对于 DR 规划来说，D-HA 要求是关键业务连续性要求。通常，通过提高冗余以消除会阻止应用程序在存储系统发生故障期间访问数据的单点故障来实现 D-HA。例如，包括冗余组件的 VSM 系统可以改进 VSM 系统容错。安装多个 VTSS 设备、冗余 SL8500 机械手和多个 RTD 目的是消除从应用程序到存储在 MVC 上的关键数据的数据路径上的 VSM 单点故障。VSM 体系结构自始至终设计成支持添加冗余组件来提高冗余并提升 D-HA。
高可用性物理磁带
Oracle 的大型机磁带自动化解决方案通过将数据的冗余副本存储在 TapePlex 内（即，由单个 CDS 映射的复合磁带内）的不同 ACS 中，可使物理磁带应用程序实现 D-HA。例如，在包含单个 TapePlex 的 IT 设备中运行的应用程序可以轻松地将磁带数据集的重复副本存储在该 TapePlex 内的一个或多个 ACS 中。这种技术可通过添加冗余介质、磁带传送装置和自动化磁带库来改进 D-HA。举个简单的例子，应用程序将关键数据集的冗余副本存储在单个 SL8500 磁带库中的两个不同盒式磁带上，该磁带库包含冗余电子部件、每个滑轨上两个机械手，并且每个滑轨上两个或多个与数据集介质兼容的磁带库连接的磁带传送装置。为了消除 SL8500 磁带库作为潜在的单点故障，又向 ACS 中添加了一个 SL8500 来存储关键数据集的更多冗余副本。为了消除 IT 设备本身作为单点故障，可以异地保管冗余数据集副本或在带有通道扩展磁带传送装置的远程 ACS 创建冗余数据集副本（图 1-4）。
如果每个物理位置都有自己独立的 CDS，即如果每个位置的硬件代表单独的 TapePlex，您也可以在不同的物理位置创建两个或多个物理磁带副本。通过使用 SMC 客户机/服务器功能并定义用于使数据集副本指向远程 TapePlex 的策略，作业可以在另一个 TapePlex 中的 ACS 中创建磁带副本而 JCL 没有变化。
高可用性虚拟磁带
VSM 提供了 MVC 多路复用和群集技术，以使大型机虚拟磁带实现 D-HA。VSM 多路复用涉及在一个或多个 ACS 中创建多个 MVC 副本（例如双工、四工）以提高冗余（图 1-5）。接收多路复用副本的 ACS 可以是本地磁带库或带有通道扩展磁带传送装置的远程 ACS。VSM 迁移策略控制驻留在 VTSS 缓冲区中的 VTV 到本地或远程 MVC 的移动，这种移动可能会循环到异地保管库。
VSM 群集由两个或多个为了通过通信链路 (CLINK) 进行数据交换而联网的 VTSS 设备（节点）组成。CLINK 是单向或双向通道。最简单的 VSM 群集配置包括两个 VTSS 节点，它们在使用单向 CLINK 连接的同一个 TapePlex 中，但是一般部署双向 CLINK（图 1-6）。每个群集节点可能位于不同的站点。VSM 单向存储策略控制通过单向 CLINK 从 VTSS A 到 VTSS B 的虚拟磁带卷 (virtual tape volume, VTV) 自动复制。双向存储策略和双向 CLINK 允许从 VTSS A 复制到 VTSS B，反之亦然。
借助 VSM 扩展群集，可以在一个 TapePlex 中的三个或更多 VTSS 设备之间建立多对多连接，从而实现更高级别的数据可用性（图 1-7）。如图所示在一个 TapePlex 内的两个或多个站点中安装 VTSS 群集设备可通过消除每个站点作为单点故障来提高冗余。
Oracle 的 LCM 产品可通过管理保管库与生产磁带库之间的回收过程来简化 MVC 卷的异地保管过程。当过期数据量超过指定的阈值时，LCM 保管功能将计划退还保管的 MVC 卷。
VSM 跨 Tapeplex 复制 (Cross-Tapeplex Replication, CTR) 群集允许 VTSS 群集设备位于不同的 Tapeplex 中，并提供了将 VTV 从一个 Tapeplex 复制到一个或多个其他 Tapeplex 的功能，从而通过单向或双向 CLINK 启用多对多群集复制模型（图 1-8）。发送和接收 Tapeplex 可能位于不同的站点。复制的 VTV 作为只读卷装入到接收 Tapeplex 的 CDS 中。这样提供了强大的数据保护，以防在 Tapeplex 中运行的应用程序对其进行更改。接收 Tapeplex 的 CDS 还会指明 CTR 复制的 VTV 副本由发送 Tapeplex 拥有，作为附加保护措施，CTR 将确保 Tapeplex 无法修改它不拥有的任何 VTV。
D-HA 和同步点恢复
创建物理卷的多个副本（MVC 或非 MVC）可以改进数据冗余，但是这些副本对同步点恢复提出了特殊注意事项。对于同步点恢复来说，最重要的一方面就是确保在同步点创建的数据保持只读状态，同时对灾难恢复用途仍然有效。这意味着可用于灾难恢复的物理磁带卷副本必须保持只读状态。要做到这一点，一种方法是将这些副本发送到不存在磁带处理功能的异地保管库位置。请注意，任何经过更改的未受保护的副本都不可用于同步点恢复，因为更新的内容不再反映关联的同步点。虚拟磁带环境添加了一个额外的维度用于管理同步点恢复的多个卷副本。VTV 副本可同时存在于多个 VSM 缓冲区中以及多个 MVC 上。即使当给定 VTV 的所有 MVC 都异地保管时，也可修改留在 VSM 缓冲区现场的 VTV 副本。更新的驻留在缓冲区中的 VTV 副本不得用于同步点恢复，除非该 VTV 属于一个新的同步点，而该同步点使异地保管的副本对灾难恢复用途无效。
执行真正的灾难恢复
真正的灾难恢复操作的成功依赖于具备适当的 DR 站点、训练有素的人员、久经验证的 DR 过程和可恢复的生产工作负荷，生产工作负荷的同步点要满足定义的 RPO，并且所有输入数据和必要的系统元数据能够达到这些 RPO。输入数据和系统元数据必须在需要时可在 DR 站点访问，并且必须在所需的状况级别可用。经过仔细的规划、充分的准备和精心编排的执行，真正的灾难恢复操作可以按规划顺利开展以实现定义的 RPO 和 RTO。当 DR 站点充当生产站点时，在 DR 站点生成的生产数据必须得到充分保护。例如，假设 D-HA 体系结构要求生产工作负荷在三个远程站点复制冗余数据副本，并且假设 DR 站点在发生灾难之前是这些远程复制站点之一。当生产站点发生灾难而其工作负荷移至 DR 站点后，DR 站点无法再充当目前在该站点本地运行的生产工作负荷的远程复制站点。要满足三个远程复制站点的 D-HA 要求，只要生产工作负荷仍在 DR 站点上运行，就必须使新的第三个远程复制站点联机。此示例说明了全面分析 D-HA 要求如何帮助 DR 规划者明确生产移至 DR 站点后必须满足的所有关键 D-HA 要求。全面的 DR 规划不仅包括在 DR 站点复原生产的活动，而且还包括当生产站点得到修复且为业务做好准备时腾出 DR 站点的过程（假定 DR 站点只是临时的替代生产站点）。例如，当生产站点准备好恢复运行时，必须在该站点复原生产数据。方法包括在 DR 站点与生产站点之间建立双向群集，为在 DR 站点运行的生产工作留出足够的时间，让其通过数据复制重新填充以前的生产站点。但是，可能有必要直接将物理 MVC 传送回复原的生产站点，这也是更及时、更高效的方法。选择的方法取决于灾难恢复后的要求。
规划 DR 测试
真正的灾难恢复就绪性通过测试在指定的 DR 测试站点恢复生产工作负荷的 DR 系统和过程的效率和效用进行评估。DR 测试环境可能是一个专用的 DR 测试平台，但通常在生产和 DR 测试系统之间共享资源更经济。与生产并行执行且使用与生产共享的资源的 DR 测试称为并发 DR 测试。如果某个应用程序必须在生产和 DR 测试系统上并行执行，则 DR 规划者应该确保这两个应用程序实例在并发运行时不会相互干扰。在单独的 LPAR 上隔离生产和 DR 测试系统并限制从 DR 测试系统访问生产数据通常可以提供足够的隔离。DR 测试通常逐渐执行，以允许在不同时间对不同应用程序进行针对性测试，而不是一次测试整个生产环境的恢复。针对性测试是减少 DR 测试系统所需专用硬件量的关键所在。例如，如果某个可恢复应用程序的 DR 测试只需要一小部分 VSM 资源，则这些资源可以在生产和 DR 测试系统之间共享，并在 DR 测试周期内重新分配给 DR 测试系统。这种方法可以减少 DR 测试系统硬件费用，但是冒着在运行 DR 测试时会影响生产系统性能的风险。但是，通常 DR 测试周期只将很小比例的共享资源专用于 DR 测试系统，缩小的生产环境不会受到并行 DR 测试很大的影响。然而，某些组织有针对更改或影响生产的策略来促进 DR 测试。审计员可能要求 DR 测试结果与生产结果精确匹配以证明 DR 恢复过程。满足这项要求的一种方法是，就在计划的生产运行前建立一个同步点、保存生产结果的副本、在 DR 测试站点恢复该同步点的生产运行，并将输出与保存的生产结果进行比较。结果之间的任何差异突出了必须调查的差距。如果未能及时弥补差距，会使组织的真正灾难恢复能力面临风险。无论 DR 测试设计成恢复复杂的工作负荷还是单个应用程序，都必须使用用于真正灾难恢复的步骤执行 DR 测试过程。这是证明 DR 测试成功的唯一一种可靠方法。
DR 测试的数据移动
在 DR 测试站点为 DR 测试暂存应用程序数据有两种方法：物理数据移动和电子数据移动。物理数据移动涉及在下述称为“物理导出/导入”的过程中将物理盒式磁带传送到 DR 测试站点。电子数据移动使用远程磁带机、远程 RTD 或 VSM 群集技术在 DR 测试站点创建应用程序数据副本。采用这两种数据移动方法均可进行 DR 测试，但是电子数据移动可避免物理数据传输以及与丢失磁带有关的任何潜在问题等等。电子传输通过将数据放在真正的灾难恢复需要的位置，或者通过在 DR 测试周期之前将数据暂存在 VSM 缓冲区中，还能缩短访问数据的时间。虚拟卷的电子数据移动可以使用 VSM 扩展群集在单个 Tapeplex 中完成，也可以使用跨 Tapeplex 复制在两个 Tapeplex 之间完成。对于单个 Tapeplex 内的数据，Oracle 的 Concurrent Disaster Recovery Test (CDRT) 软件可简化 DR 测试。
通过物理导出/导入进行 DR 测试
假设您要为一个使用虚拟和物理磁带的生产应用程序执行 DR 测试。您的目标是通过重复最近的生产运行并验证测试输出是否与最近的生产输出匹配来在 DR 测试站点测试该应用程序。在准备过程中，您需要保存生产运行使用的任何输入数据集的副本以及生产输出的副本以便进行比较。假设 DR 测试站点已隔离，它与生产站点不共享任何设备。您可以采用以下物理导出/导入过程来执行 DR 测试。
生产站点：
-
创建必需的 VTV 和物理卷的副本。
-
导出这些 VTV 副本。
-
从生产 ACS 中弹出关联的 MVC 副本和物理卷副本。
-
将弹出的 MVC 和物理卷传送到 DR 测试站点。
DR 测试站点：
-
将传送的卷装入 DR ACS。
-
将 OS 目录和磁带管理系统与装入的卷同步。
-
导入 VTV/MVC 数据。
-
运行应用程序。
-
比较结果。
-
弹出为该测试装入的所有卷。
-
将弹出的卷传送回生产站点。
生产站点：
-
将传送的卷装回生产 ACS。
该过程允许 DR 测试安全地与生产并行进行，因为 DR 测试系统与生产系统隔离。DR 测试系统有自己的 CDS，在上述 DR 测试过程中，会将卷信息输入 DR 测试 CDS 以便为 DR 测试做好准备。这样允许恢复的应用程序以在生产系统中使用的卷和数据集名称进行测试。对于虚拟磁带数据集，Oracle 的 LCM 软件保管功能可简化将 VTV 放置到 MVC 上的过程，并简化上述往返步骤，即在生产站点导出和弹出卷、在 DR 测试站点导入这些卷以及弹出这些卷以便移回生产站点。物理导出/导入会使站点产生物理磁带处理费用以及在生产和 DR 测试站点之间传送盒式磁带的快递费用。由快递移动的敏感数据应该在加密的盒式磁带中传送。DR 测试时效性受在站点之间传送盒式磁带以及处理移动的盒式磁带所需时间的影响。
通过 CDRT 进行 DR 测试
经过规划并且在生产和 DR 站点配备足够的硬件后，CDRT 结合电子数据移动可避免将物理盒式磁带传送到 DR 站点，并使并发 DR 测试较之维护隔离的专用 DR 测试站点更经济。借助 CDRT，几乎可以对可想象的任何生产工作负荷、配置、RPO 或 RTO 进行 DR 测试。DR 测试过程将包括一些额外的步骤来启动 CDRT 以及在 DR 测试后进行清除。在借助 CDRT 运行 DR 测试之前，您应该以电子方式将测试所需的所有应用程序数据和系统元数据（OS 目录信息和磁带管理系统信息）移至 DR 测试站点。您可以使用 VSM 群集或通过将 VTV 副本迁移到 DR 站点的 MVC 来以电子方式移动应用程序数据。然后使用 CDRT 为 DR 测试系统创建特殊的 CDS 来镜像生产 CDS。生产和 DR 测试系统是单独的环境，DR 测试环境将使用特殊的 DR 测试 CDS 而非生产 CDS。由于 CDRT 根据生产 CDS 中的信息创建 DR 测试 CDS，因此它包含在 DR 测试之前以电子方式移至 DR 测试站点的所有卷的元数据。这样可使 DR 测试应用程序使用在生产系统中使用的卷序列号和磁带数据集名称。CDRT 在 DR 测试系统上实施操作限制，以防止 DR 环境干扰生产环境。您可以使用 ELS VOLPARM/POOLPARM 功能为 MVC 定义单独的卷序列号范围并暂存 VTV 使其由 CDRT 专用，从而加强这些保护。CDRT 允许 DR 测试系统从生产 MVC 中读取数据并将数据写入自己的将在每个 DR 测试周期过后以逻辑方式擦除的专用 MVC 池。对于虚拟磁带应用程序，CDRT 在 DR 测试周期内至少需要一个专用的 VTSS 设备。可以从生产系统临时重新分配这些专用的 VTSS 以促进 DR 测试，并且 DR 测试 VSM 系统可以与生产工作负荷并行访问生产 ACS。图 1-9 和图 1-10 阐明了如何拆分生产 VSM 群集以将群集设备借给 CDRT DR 测试系统，在本例中是 DR 测试站点的 VTSS2。拆分该群集时，您必须更改生产策略以用迁移替换复制，这样 VTSS1 将在 DR 站点的 ACS01 中创建冗余 VTV 副本，并且拆分群集时 VTSS1 不会填充容量。VTSS2 将在生产系统中脱机而在 DR 测试 LPAR 中联机。在图 1-9 中，CDRT 从生产 CDS 的远程副本创建了 DR 测试 CDS。只有生产系统可以在整个 DR 测试周期内访问 VTSS1 和 ACS00 中的卷，只有 DR 测试系统可以访问 VTSS2。生产和 DR 测试系统共享并发访问 ACS01 中的卷。图 1-9 和图 1-10 在 DR 测试站点维护生产 CDS 的远程副本（例如通过远程镜像），以确保 DR 站点有最新的生产 CDS 可用于真正的灾难恢复。但请注意，由 CDRT 从远程 CDS 副本创建的 DR 测试 CDS 是生产 CDS 的特殊 DR 测试版本，只能由 CDRT 使用。在 DR 测试周期结束后重组生产群集之前，必须清除 DR VTSS 以避免生产数据丢失，因为如果 VTSS2 包含一个较新的 VTV 版本而该版本也存在于 VTSS1 中，将会发生这种情况。您还必须在重组群集后更改生产策略以从迁移恢复为复制。如果无法如此处所示拆分生产群集，替代方案是在 DR 站点专为 DR 测试维护一个单独的 VTSS。在这种情况下，将从 MVC 副本撤回测试所需的 VTV。
通过 VSM 跨 Tapeplex 复制进行 DR 测试
VSM 跨 Tapeplex 复制支持对称的群集生产 Tapeplex 设计，这些设计可促进 DR 测试而无需使用 CDRT、无需单纯为了 DR 测试的专用 VTSS 硬件并且无需为 DR 测试更改生产环境。例如，CTR 允许每个生产 Tapeplex 将数据复制到同一个 CTR 群集中的其他生产 Tapeplex。生产 CTR 对等群集可消除对专用 DR 测试站点的需要。CTR 支持多种不同类型的群集 TapePlex 设计并促进任何生产工作负荷或配置（具有任何可行的 RPO 或 RTO）的 DR 测试。举个简单的例子，一个双向 CTR 群集对称地将两个生产 TapePlex 相连，每个 TapePlex 将数据复制到另一个 TapePlex（图 1-11）。接收 TapePlex 以只读状态将复制的 VTV 装入其 CDS，并将 VTV 标记为由发送 TapePlex 拥有。在此示例中，TapePlex A 应用程序的 DR 测试涉及在 TapePlex B 上复制应用程序数据以及在 TapePlex B 上恢复应用程序。
这种对等 CTR 群集设计的对称性意味着，在对等站点进行测试的恢复的应用程序在 DR 测试期间的运行与在生产期间一样。对等 CDS 包含 DR 测试需要的所有复制的卷信息，DR 测试与生产并行进行，并且相同的 VTSS 硬件支持由生产和 DR 测试工作负荷并发使用。生产 VTSS 群集可能存在于每个 TapePlex 中，并且无需拆分即可在 TapePlex 之间共享硬件以便进行 DR 测试。从中执行应用程序 DR 测试的生产 TapePlex 无法修改任何 CTR 复制的 VTV，因此所有复制的生产数据在 DR 测试周期内完全受到保护。最重要的是，基于 CTR 的 DR 测试可保证经验证的 DR 测试过程在真正的灾难恢复期间将产生完全相同的结果。如果尝试更新一个 CTR 复制的 VTV，而它用来将应用程序标识为修改现有输入数据集的一个应用程序，则 SMC 主机软件将发出一条消息。按照上述管理同步点的最佳做法，您应该确保生产环境在应用程序修改该数据集之前保存该数据集的副本，以备同步点恢复需要备份副本。