云灾难恢复的主要影响因素及实施流程

 

位置。云恢复服务的位置在哪里？灾难恢复服务离得越远，来回获取数据的延迟时间越长——这将对复制性能产生负面影响。此外，还有合规性方面的考虑。存储数据所在的国家或地区是否与用户数据监管要求相违背？用户还需要考虑当需要在灾难恢复中运行数月时云灾难恢复供应商是否是自行实施灾难恢复。

网络。网络带宽是否足够满足用户需求，用户将如何被计费？将如何实现用户网络与云恢复服务供应商网络的互联？是否有安全工具和流程来确保隔离用户网络与其他客户的网络？

故障转移/故障恢复。将应用迁往云需要某种播种流程。这可通过网络实现，或者可能需要用到由云供应商发送和上传的物理备份设备。查看应用可以如何快速地使用登上基于云的灾难恢复服务。故障恢复则依赖于故障转移/播种。在某个阶段，需要将应用迁回它们的生产位置。任何数据更新和操作系统打补丁都需要迁回数据，而这样做是需要花一点时间来实现的。部分灾难恢复计划可能只是发送应用程序数据和在云计算中运行一个重复的应用，从而满足服务水平协议。

SLA。除了恢复点目标，恢复时间目标和服务水平目标以外，云灾难恢复供应商还应提供SLA。这些指标将决定诸如网络响应时间、灾难恢复调用速度以及具体流程等参数。还应当有针对云硬件可用性的SLA——一般不会迁移至具有比主站点更差可用性的DR平台。

实施方面，一旦完成背景规划和云恢复服务选择，就需要进入新的灾难恢复流程，这可能需要一些额外的工作来实现，如：

裸机服务器的虚拟化。可能需要将一些应用程序迁入虚拟机，而迁移至云灾难恢复则为证明工作有效性提供了机会。

现有备份流程的改变。正在使用的特定备份工具有可能会改变，或者如果将使用两个备份方法那么可通过云灾难恢复予以加强。操作流程将需要审查和修改以便于它能够与新备份系统相匹配。

基础设施的改变。可能需要开发一些附加的服务，特别是DNS、DHCP和AD。可能需要某些网络改变以便于允许流量在现场备份系统和云计算备份供应商之间流动。

测试。应当定期对灾难恢复流程进行测试。基于云的灾难恢复为测试灾难恢复提供了一个更简便的方法，而基于云的镜像可在网络中被更轻松地隔离开，而不会影响生产服务。很多云恢复服务供应商都将这一设施作为他们产品的一部分。

最后，应当定期对灾难恢复计划和流程进行审查和测试，以确保它仍然能够提供一个满足设计目标的产品。所有的灾难恢复产品应当被视为一个不断变化发展的系统，它的变化是为了不断满足应用需求，并最终满足业务需求。