在云上创建数据恢复计划，跟踪基础架构、DR要求和可能的故障转移持续时间非常重要。公共云为IT部门提供了最佳机会来实施业务连续性/灾难恢复计划，而无需花费巨资建设专属数据中心。有了云数据恢复系统，云可以用作基本数据的存储库，甚至可以在发生重大系统故障时用作运行应用程序的地方。制定DR计划时，第一步是查看用于提供IT服务的应用程序，并确定在发生灾难时需要保护的内容。这意味着创建需要运行的应用程序和服务的清单。许多企业已将虚拟化作为其核心服务器部署模型；但是，仍然需要考虑物理服务器。全面的云数据恢复计划应包括以下内容：用于交付基础架构的物理和虚拟服务器。其中包括ActiveDirectory(AD)服务器、DNS/DNCP服务器和应用程序。用于交付应用程序的物理服务器。服务仍然在物理服务器上交付需要有一个更好的理由；这可能包括扩展和性能要求，或使用自定义硬件和操作系统。然而，云恢复服务可能能够帮助虚拟化其中的一些组件。用于交付应用程序的虚拟服务器。可能有数十个或数百个虚拟机用于实现应用程序。每个都需要被识别和记录，查看存储、内存和虚拟处理器要求。最好提前确定基础设施服务器，因为这些系统在灾难发生时需要最长的时间来恢复服务。云上运行的AD、DNS、DNCP服务可以预先配置并与其内部实例同步，使容灾过程更简单、更快速。了解网络配置对于云上的DR成功运行至关重要。这意味着花时间了解网络层应用程序之间的相互依赖关系，包括安全和防火墙配置。与云数据恢复相关的问题是：是否有任何应用程序或服务器之间存在延迟依赖性？是否有东西向防火墙规则来管理站点内流量？面向客户的应用程序的外部带宽要求是什么？确定云数据恢复需求假设在发生灾难时，每个应用程序都需要立即恢复，这是不切实际的。相反，应根据一组标准确定应用程序的优先级，以确定需要以多快的速度以及哪些同步的系统和数据恢复运行。在决定恢复应用程序的服务级别时，可以使用许多指标：恢复时间目标。它衡量在顺序备份启动和运行之前可以容忍多少停机时间；通常以分钟或小时为单位。例如，RTO为零意味着绝对不能容忍中断，而RTO为一小时意味着应用程序必须在灾难恢复后的一小时内恢复。恢复点目标。它衡量应用程序再次运行后可以容忍丢失的数据量。零RPO意味着所有数据都必须恢复到灾难点，而24小时RTO意味着数据或系统可以在恢复后24小时内过时。服务水平目标。SLO衡量整个应用程序的恢复情况。例如，协议可能是在四小时内恢复90%的应用程序。更严格的SLO需要更多的基础设施支持，可能需要更多的人力来实现，因此留有一定的灵活性可以帮助管理DR的成本。SLO允许对数据和应用程序进行优先级排序。例如，在线信用卡处理系统要求零RPO和极低的RTO。期望这样的系统永远不会丢失信息是合理的。在另一个极端，报告应用程序可能能够容忍24到48小时的数据过期，因为它的数据是从其他应用程序中提取的。大多数其他系统都介于这两个极端之间。建立适当的云数据恢复要求包括与应用程序的业务所有者进行沟通，因为他们了解其应用程序的重要性。根据经验，企业主认为他们所有的应用程序都很重要——直到他们了解恢复成本。因此，他们可以了解不同选项的成本评估。服务水平的最后一点是：一些严格的要求，比如零PRO，云端容灾是做不到的，因为本地和云端位置之间会有延迟。这些应用程序需要从基于云的DR中排除，并且应该提供更多定制的DR产品。DR服务将运行多长时间？***需要讨论的是该服务将在公有云上运行多长时间。做出这样的决定取决于发生的事件的类型。并非所有灾难都会导致所有在线功能崩溃。还会有边缘事件类型，例如：服务器丢失。物理服务器或虚拟服务器主机。虚拟服务器的丢失可能会很严重，也可能不会很严重，应用程序需要移动到DR模式下运行。缺少多个系统。例如，如果共享存储阵列出现故障，则可能会丢失多个应用程序。数据中心丢失。在最坏的情况下，整个数据中心都丢失或无法访问。所有服务都需要运行在容灾模式下。有时，服务需要移动数小时或数天。当整个站点丢失时，可能需要运行DR服务数周或数月，直到重建以前的设施。云恢复服务按使用的活动服务计费，因此这是选择DR服务时的重要考虑因素。
