在灾难恢复中，一个要点是如何快速有效地执行灾难恢复技术方案，将关键业务系统从破坏性事故中重新运转起来。典型的方案文档可能有几十上百页，当紧急状况发生，分秒必争，这时却需要很长时间来找到正确信息，组织适合的人力，然后执行计划。

恢复关键数据的系统和平台选择有很多，而已在使用的故障恢复管理软件技术是功能完整并在实践中被证明行之有效的。一个典型例子是“切换”软件正实时监控着IT资源，如服务器，发现可能出现的问题。如果生产系统突然崩溃，切换软件检测到环境变化，更新DNS记录，将数据处理重定向到可用IT设备。

当然，这一方案是假定备份IT设备是可用的——最好位于另一个地点——并且被配置成可以接管故障系统的处理工作。

故障恢复软件也应该具有“回切”功能，即当故障设备重新恢复正常运转，可更新DNS将处理流程重定向回原生产系统。

上面的例子适用于一个或两个设备故障，没有其它生产系统受到影响的场景。但是，如果一个巨大的灾难损坏甚至摧毁整个建筑，包括办公室，工作站，通信系统，数据系统，网络接入设备，存储设备及其它IT资产，这时又该怎么办？

针对这一挑战，一些提供基于云的故障恢复产品的公司提出了很多有用方案，这些方案直观易用，激活方便。例如EvolveIP、Axcient以及Unitrends。这些产品可复制全部或者部分办公室环境及IT基础设施，从而可以“恢复”为一个基于云的办公环境。

图一显示了正常场景下的基于云的灾难恢复产品。基于云的IT环境备份定期更新以保障[它备份的]系统和数据都是最新的。

图二显示当主IT环境和办公区域突然发生故障不可访问时，一条去往云灾难恢复系统的命令会触发连续步骤将生产活动重定向到基于云的办公环境。

这是一个简单例子，并假设以下几点关键因素：1）员工可以从家或备用办公区接入网络；2）所有DNS表和其它相关信息都可访问并能更改做重定向服务；3）业务中断期间IT人员还可以接入网络并远程管理操作。

对于灾难恢复，这类产品到底意味着什么？首先灾难恢复现在可以作为IT运维具有战略意义的一部分工作，基于云的故障切换/回切产品使得故障恢复很容易整合到IT运维中。其二，它意味着传统的故障恢复活动在系统修复和业务恢复流程方面得到增强，尤其对于大规模恢复的应用场景。第三，对灾难恢复计划中的技术测试可以大大简化。

让我们进一步考量测试方面。当对灾难恢复计划中的数据系统部分进行测试时，备选操作从简单的桌面演习到全系统的切换/回切。创建操作手册或脚本文档是好的测试的关键部分。脚本文档记录了操作步骤，正确操作顺序，输入命令以及预期输出等。这通常是数据系统测试最重要的部分，因为恢复步骤的顺序必须正确，输入命令必须准确，否则测试失败，而当真正的灾难来临时，系统故障将对公司产生负面影响。

假设我们能够将上面的操作自动化，将测试以简单得如同单击按钮（或者几个按钮）的方式来执行。尽管对很多人来说，“简化灾难恢复”依然是陌生的新想法，但它距离我们比你所意识到的更近。

假定你已经对某些关键IT资产或整个办公环境配置了一个基于云的副本，如果灾难恢复管理软件将主生产系统重定向到这个可见的基于云的副本，那么系统的“恢复”可以在瞬间完成。相比将IT人员和员工搬到另一地点，这样的恢复与重启无疑要迅捷得多。当然，我们假定生产数据存在的文件和数据库是可以立即备份到云端的，更进一步我们其实是假定了充足的网络带宽以保障数据资产能复制到云端。还有重要的一点，我们假定能在云端启动服务器。

你很自然地会认真考虑这样的产品，尤其是它们的云端计算，存储和复制的成本是否满足你对恢复时间和恢复点的要求。

现有的故障恢复计划和流程将需要修改或重写。你的计划会变得更简单，尤其是对数据系统，工作数据、数据库、通信服务、网络服务以及其它IT领域进行恢复的部分。恢复流程中的这些改进将提高数据系统恢复成功的可能性。

随着云技术和故障恢复管理系统的显著提高，“一点即可”的故障恢复正实实在在成为一种现实。如果你的IT故障恢复需求包含快速切换和回切，并且可能在一个大规模应用环境下，那么是时候开始调研本文所谈的解决方案了。