虽然虚拟化解决方案在灾难恢复方面具有诸多优势，但将所有服务器整合于一个vSphere平台，并且如果不维护一个远程灾难恢复站点，仍然会给你的系统带来隐患。

　　每个企业都需要灾难恢复计划，但是研究显示，只有不到50%的企业有相关计划。随着虚拟化使工作负载在不同物理服务器间更加容易地迁移，在第二数据中心需要灾难恢复计划，无论是物理环境还是虚拟环境都是必要的。

　　幸运的是，虚拟化灾难恢复正变得越来越易于操作。下面我们看看构建VMware虚拟化灾难恢复站点的需求。

　　为什么虚拟化灾难恢复比以往更加容易？

　　服务器采用以下措施来简化灾难恢复：

　　服务器的操作系统和应用不再和特定的物理服务器硬件绑定。

　　虚拟机具有可迁移性，你可以在任何vSphere服务器上运行它们。

　　依靠虚拟化特性，你可以完成虚拟机的克隆、快照和移动。

　　VMware高可用性和分布式资源调度这些高级特性能够帮助机构尽快地从灾难中恢复，借助于资源分配避免系统缓慢和中断。

　　从公司开始实施虚拟化以来，已经有众多特性让灾难恢复变得更加容易。比如，vStorage APIs for Data Protection中的CBT(change block tracking)特性，允许备份灾难恢复工具轻易地找出虚拟机磁盘文件中发生过改变的块，之后这些发生改变的块通过广域网复制到远程VMware灾难恢复站点。除此之外，基于软件的灾难恢复解决方案，取代了硬件工具，高可用性使得所有规模的公司都能够更轻易地负担复制虚拟机的开销。

　　规划远程VMware灾难恢复站点

　　在构建一个远程VMware灾难恢复站点之前，有许多问题需要考虑。毕竟，恰当的灾难恢复计划能够避免浪费大量的资金在本不需要的设备和设计上。

　　让我们来看在进行远程VMware灾难恢复站点规划时需要考虑的方面：

　　清查现有的基础设施，在彻底理清一个主要数据中心的资产之前，你不能对它开始复制。RVTools和Veeaminc.Reporter（免费版）是两个不错的用于vSphere基础设施免费工具。

　　了解应用程序和它们的依存关系。当你对应用程序如何工作和它们的依存关系有初步的了解之后，你将会知道哪些应用程序需要抵抗灾难的能力。如果你的灾难恢复计划只能够在一部分服务器上实现故障转移，那么那些依靠多个服务器的应用程序可能会受到影响。要考虑到（主站点和备份站点）存储和网络架构之间任何潜在的差异，确保程序即使在不同的环境下，也能够按照预期实现把故障转移到备份站点。

　　不要忘记你的客户。因为你运行维护所有的服务器和应用程序，并不意味着终端用户就能够访问他们。怎样替换他们的桌面和应用程序？他们怎样进行远程访问？

　　应用程序区分优先级处理。如果你的远程VMware灾难恢复站点不能提供和生产环境数据中心同样的容量，处理的优先级是什么？哪些应用程序需要优先进行恢复？

　　建立恢复点目标（PRO）和恢复时间目标(PTO)

　　你的公司需要在多长时间内将虚拟机（包括它运行的应用程序）恢复上线，24小时的PTO意味着业务能够在缺少虚拟机24小时的情况下继续工作。

　　你能够接受多少数据的丢失？如果数据每小时复制到第二数据中心，当灾难发生时，有可能最多丢失之间59分59秒的数据。如果这样是可接受的，不会严重地影响业务，那你的PTO可以设定为一个小时。

　　设定你的预算。决定你的公司愿意投入多少在灾难恢复站点上（你可能永远都不会使用它）。如果公司询问你的花费，你可能必须创建一个需求资源的列表来计算和压缩它。

　　至此，我们介绍完了在构建远程VMware灾难恢复站点之前需要做的准备工作。后续文章里，我们将继续讲解怎样具体实现构建远程VMware灾难恢复站点。