创建云上的数据恢复计划，很重要的一点是持续跟踪基础架构，DR需求和可能的故障转移持续时间。

公有云给IT部门提供了绝佳的机会来实现业务的持续性/灾难恢复计划，而无需花费巨资构建独享的数据中心。有了云数据恢复系统之后，云就可以用作基本数据的存储库或者甚至当主要系统出问题时运行应用之处。

当构建DR计划时，第一步是查看用来交付IT服务的应用，并且决定灾难发生时需要保护什么。这意味着创建需要运行的应用和服务的清单。很多企业已经转向虚拟化作为其核心服务器的部署模型；但是，仍然需要考虑物理服务器。完善的云数据恢复计划应该包括如下：

用来交付基础架构的物理和虚拟服务器。这些包括活动目录（AD）服务器，DNS/DNCP服务器和应用。

– 用来交付应用的物理服务器。为什么还在物理服务器上交付服务，这需要有好一点的理由；这可能包括扩展和性能要求，或者使用自定义硬件和操作系统。但是，云恢复服务可能能够帮助虚拟化其中一些组件。

– 用来交付应用的虚拟服务器。可能有几十台或者上百台虚拟机用来实现应用。每台都需要确认和记录、查看存储、内存和虚拟处理器需求。

最好提前确定基础架构服务器,因为当灾难发生时这些系统需要第一时间恢复服务。可以预配置在云上运行的AD、DNS和DNCP服务，并且和它们的内部实例同步，让DR流程更加容易，也能够更快实现。

要想让云上的DR能够成功工作，理解网络配置至关重要。这意味着需要花时间理解网络层的应用之间的相互依赖关系，包括安全和防火墙配置。云数据恢复相关的问题有：

– 是否有应用或者服务器互相之间有延迟依赖？

– 是否有East-West防火墙规则来管理站内流量？

– 面向客户的应用的外部带宽需求是什么？

确定云数据恢复需求

假定在灾难事件发生时，每个应用都需要立即恢复，这并不太实际。相反，应该基于一系列条件来区分应用的优先级，来决定需要多快，以及哪些同步系统和数据需要恢复运营。在决定恢复应用的服务等级时，可以使用一些标准来进行度量：

恢复时间目标。它衡量在应序备份并且运行之前可以容忍多长的下线时间；通常以分钟或者小时计量。比如，零RTO表示完全不能容忍掉线，而一小时的RTO意味着应用必须在DR发生的一小时内完成恢复。

恢复点目标。它衡量一旦应用再次运行时可以容忍丢失多少数据。零RPO意味着所有数据都必须恢复到灾难发生点，而24小时的RTO意味着恢复后数据或系统可以过时24小时。

服务级别目标。SLO衡量整体应用的恢复情况。比如，协议可能是在四小时内恢复90%的应用。越严格的SLO要求越多的基础架构支撑并且可能需要越多的人力才能达到，因此留有一定的灵活度有助于管理DR的费用。

SLO 允许区分数据和应用的优先级。比如，一个在线信用卡处理系统要求零RPO和非常低的RTO。期望这样的系统永远也不会丢失信息是合理的。另一种极端情 况是，负责报告的应用可能能够容忍24到48小时的数据过期时间，因为其数据是从其他应用里抽取出来的。其他系统大多数处在这两种极端情况之间。

建立正确的云数据恢复需求包括和应用程序的业务所有者沟通，因为他们了解其应用的重要程度。从经验上看，业务所有者会认为其所有应用都很重要——直到他们了解恢复所需的费用为止。因此可以告诉他们不同方案的费用评估。

服务级别的最后一点是：一些严格的需求，比如零PRO，基于云的DR是无法达成的，因为本地和云位置之间会有延时。需要将这些应用排除在基于云的DR之外，并且提供更多定制的DR产品。

DR服务会运行多久？

最后需要讨论的是，服务会在公有云上运行多久。做这样的决策依赖于发生的事件类型。并非所有灾难都会导致所有在线功能的崩溃。还会存在一些边缘事件类型，比如：

服务器丢失。要么是物理服务器，要么是虚拟服务器主机。虚拟服务器的丢失可能很严重，但也可能不严重，应用程序需要转而运行在DR模式。

多系统丢失。比如，如果共享存储阵列出问题的话，可能会失去多个应用。

数据中心丢失。在最坏的情况下，整个数据中心都丢失了，或者访问不了。所有服务都需要运行在DR模式下。

有时候，服务需要移动几个小时或者几天。当整个站点都丢失时，需求可能是运行DR服务几周或者几个月，直到重建了之前的设备。云恢复服务会为所使用的活动服务计费，因此在选择DR服务时这是很重要的考核点。