关键服务器和积极的恢复目标

对于必须开启，而且要保持开启状态的应用程序，在多个地方，转为集群或者故障转移负载平衡，是对要跨地域复制存储的一个解决办法。在存储区域网络(SAN)间复制是为了进行异地存储，这种异地存储可能会成为一个完整的远程数据中心。当灾难发生时，异地存储会用于主机的恢复。

通过使用Hyper-V虚拟机，可以不像标准的物理服务器，使被复制后的存储区域网络中可以包含虚拟硬盘。这样就可以进行故障转移。简单地将复制后的存储区域网络上线，并以很小的数据损失，将其中的虚拟硬盘加到主机配置中。再提醒一下，操作必须要小心，因为这会让某些应用程序处于一个不稳定的状态，并可能会需要进行真正的恢复或者用别的恢复方法来进行处理。

在Hyper-V R2中，可以通过GeoClusters使用集群共享卷(Cluster Shared Volumes CSV)。这让您可以建立一个Hyper-V集群并让其横跨多个位置。虽然这样做的好处是可以进行自动化的故障转移，其缺点是太复杂并且需要特定的硬件。换句话说，您需要用一个服务器和存储区域网络设备匹配的温备份站点(warm site)来做故障转移。这个技术的关键是存储是跨站点复制的。可是再次提醒，微软没有为这个存储问题提供解决方案。幸运的是，SteelEye Technology、EMC以及其它厂商的产品解决了这个问题。

未来的云选项

微软也许会作为支持无站灾难恢复形式代表的Windows Azure，很可能是即将可用的另外一个选择之一。

虽然现在已经可以将虚拟硬盘移到Azure云里，其它的一些问题，例如私有网络和恢复时间仍在发展中。在未来，尽管您可能不能对整个基础设施进行复制，但时间会证明，Windows Azure对像网站和SQL Server数据库这样的数据中心的特定设备是有价值的。

总的来说，尽管微软Hyper-V的灾难恢复解决方案还没有达到VMware的级别，但不要忘了，在VMware的恢复解决方案中也有相当多的脚本。灾难恢复——即使是一个低成本的计划——可以在少量的测试和对您需求很好理解的基础上开发出来。但前提是，要熟悉您可以有哪些选择，因为知道如何管理现有的Hyper-V环境，并基于RTO和RPO目标做出正确的规划对成功的恢复是至关重要的。