当构建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服务时这是很重要的考核点
更多Linux咨询请查询www.linuxprobe.com