灾难恢复（DR）是保障，是基础设施，是一套流程，尽管公司不会频繁使用，但需要时却十分关键。然而，为了使它有价值，灾难恢复计划（DR plan）和基础设施必须经过测试。

历史上，对灾难恢复产品的测试是困难，费时和昂贵的，因此它常常被忽视。然而，服务器虚拟化，复杂的灾难恢复软件以及云计算使得定期的灾难恢复测试变得可行并且划算。

本地灾难恢复测试

对于单个关键服务器或存储系统故障而导致灾难时，恢复是指启动现场备用服务器上的应用程序实例。这需要在备用服务器的相应hypervisor上创建虚拟机映像的克隆副本。虚拟化平台提供的一些原生工具本可以完成这一任务，但许多公司都使用特定的灾难恢复软件，有如下原因：

这些产品可以利用快照和复制，使灾难恢复副本与主虚拟机保持高效的更新。许多产品还可以在初始克隆过程中，将一个物理服务器及其应用转化为虚拟机，然后在主虚拟机镜像发生改变时同步保持更新。掌握生产服务器的当前状态并不是一件小事，灾难恢复的规划者们必须考虑到这一点。

此外，在灾难恢复测试运行之前，获得受保护数据的一个“干净”，“停顿”的副本是非常关键的。尽管一个应用通常也可以从“脏”数据中重建，但这会增加恢复时间，并可能导致一些数据丢失。同样重要的一点是组织必须明白，除非被测试的应用被正常关闭，否则在一个真正的灾难事件中，是有可能丢失一些数据的。至少，这包括正在传输的数据，但更可能包括在最近一次“干净”的更新克隆副本后新增或修改的数据。

在测试恢复过程时，克隆虚拟机需要在备用服务器上重启，用户也都重新指向该虚拟机。如果要涉及更复杂的协议栈，如Web服务器，负载均衡器，数据库服务器等，灾难恢复软件实际上可以协调整个过程，按顺序开启每一个应用，并监控系统环境。再次重申，这并非小事，必须关注理解涉及的所有步骤，确保他们都包括在测试里。

远程灾难恢复测试

当灾难恢复使用位于远程站点的备用服务器或者位于云端，即灾难恢复服务（DRaaS）的模式，测试从本质上是相同的过程，但更新的虚拟机镜像与运行hypervisor的计算基础设施相处异地，而不像前面所述的本地备份服务器上。测试依然包括复制虚拟机的重启以及用户重定向。而区别在于，当这些虚拟机实际应用于灾难恢复中，网络延迟将开始发挥作用。

出于这个原因，一种混合的灾难恢复产品成为一个有吸引力的选择。将本地和远程两种方法相结合，在公司数据中心中运行一个故障切换服务器，并与另一个远程系统同步。

而云也日益成为一种流行的灾难恢复目标，与企业内部自建灾难恢复备用站点相比，云提供了更好的灵活性和成本效益。例如，许多DRaaS产品提供了不同的灾难恢复选项（热，温，冷应用/数据），以及不同的价位。根据特定应用的恢复时间目标（RTO），用户可以选择合适的方式以满足企业需求和预算要求。

从过去看，大多数公司的灾难恢复测试都是按照一个不那么复杂的流程，以低于定期的频率进行的，这往往削弱了灾难恢复系统的信心，至少是对那些谁都知道细节的流程而言。而现在，主要是由于服务器虚拟化的出现，灾难恢复测试变成一个简单得多的练习，并不局限于晚上和周末。结果是一个可以使人气定神闲的灾难恢复系统，就像一个好的保险所能做到的那样。