虽然一些厂商宣称故障切换能够提供即时的业务连续性和灾难复原，但BC/DR仍然是一个很大的挑战。

在6月，国家飓风中心宣布，2015年的大西洋飓风季节会是比较安静的。如果属实，这是个好消息。不那么好的消息是2013年和2014年错误的预测和这两年相对安静的风暴季节似乎已经麻痹了很多人，当谈到防灾意识时，很多人看起来是放任的态度。我看到比任何时候都要多的是像Alfred E. Neuman（你知道，他是“什么？我有什么愁？”的家伙）的态度- 这真是有点恐怖。

根据记录，美国国家海洋和大气管理局（NOAA）的估计只是：根据以往的天气和气候的行为记录进行估计。有人声称，气候变化对旧模型的影响是通过改变上层大气中的粒子能量水平来改变的。这可能在检测风暴的可能性时会限制周期性事件的相关性 - 如厄尔尼诺，改变大气压力和风速，等等。这并不是说关于风暴预测的科学在过去是准确的：例如，NOAA预测2013年是飓风活跃季节，而当年几乎没有恶劣天气。而且，一些最严重的风暴，其中包括安德鲁飓风在1992年发生时， NOAA预测该季节是飓风低活跃度的。然而，我拜访的许多公司都在从任何形式的灾难恢复中拉回损失。

一些企业和IT人员告诉我，技术改进正在否定灾难恢复规划的需求。在许多大型机应用中，人们都在讲自己运行IBM的虚拟化引擎（TS7700）将允许他们跳转到最近的RUN时间点（带倒带卸载）来自动的恢复环境。换言之，他们认为这是一个简单的过程，将进程恢复到发生中断之前的一个点，并从那里重新启动它。当然，该产品的红皮书提供了一个非常不同的观点。除了RUN时间点，您需要考虑很多因素来进行重新启动，仔细规划和测试是需要的，以确保您具备做恢复操作过程中的所有一切必要措施。厂商代表积极的叫卖，加上消费者的选择性失聪，当用户需要恢复业务时，很可能会造成很多的悲剧发生。

业务连续性的真正含义

在x86的世界里，相同的问题似乎在不断发展。有些虚拟化厂商的营销鼓动用户说“DR已死”，HA架构（意为故障转移集群）消除了DR的必要性。VMware已经开始把它的故障转移群集配置定义为内置的“业务连续性”组件。

当然，业务连续性除了一组集群服务器之间的工作负载故障转移之外，还包含一些其他的内容。

当然，业务连续性除了一组集群服务器之间的工作负载故障转移之外，还包含一些其他的内容。根据国际标准组织ISO关于“业务连续性”的定义，该活动旨在恢复的不仅是技术基础设施和数据，而且包括业务流程，人员和工作场所设施，在一个计划外中断事件中进行恢复。我对那些在ISO标准下，认为故障转移服务器集群意味着同样的事情的傻瓜表示同情，——尤其是遵从ISO标准用来满足法律或法规要求的人。

让我更直接的表明观点。要求保留的数据灾难性的丢失，HIPAA（健康保险流通和责任法案）为医疗公司建立一个很好的双重灾难保障。首先，当然，数据丢失可能会危及病人的医疗保健，这中间的运营成本会非常高。也有可能，如果公司声称符合ISO22301中的业务连续性标准，公司也要承担额外的法律后果，而事实上“一致性”只是基于某一个虚拟化厂商的服务器故障转移模式作为“即时的业务连续性”。

为什么灾难恢复规划是重要的

看，我就知道没有人愿意做灾难恢复计划。此外，大的自然灾害，如飓风，在传统上对IT系统只造成约5%的宕机时间。造成事故的原因包括计划内停机，软件故障，硬件故障，用户错误，恶意软件和病毒。所以，一些故障转移（有正在进行的数据复制）可能帮助企业避免95%的可能会导致宕机的问题。

但这不是业务连续性或灾难恢复—这仅仅是灾难防护。也是一项重要的能力，但不是一样的东西。DR和BC的规划者必须考虑不可克服的或不可避免的终端，这可能使业务受到中断的影响。您需要考虑如何操作，在任何情况下，使您的设备免受影响，以防用户访问系统和数据被切断。

首先，你需要建议一个真正可用的数据基础设施—并且在特设的基础上，其有效性可以进行测试和验证。数据复制和祈祷是不够的。你需要验证镜像和副本，以确保正确的数据被持续复制，并且数据副本被保存在一个足够远的场外位置，以免受到任何可能破坏原始数据中心的灾难的影响。

这是很多企业做不到的东西。在群集服务器后端的存储之间镜像数据，或者是本地服务器集群和场外的远程服务器集群之间镜像数据，都是不够的。你需要分析和发现所有数据—包括应用程序数据和支持文件（包括虚拟机管理程序软件，驱动程序等等），这些数据会在备用主机重新启动实例来承接工作负载。然后，你需要确定目标恢复集群的物理位置，你要明白，远距离引起的时延和网络抖动可能对数据的传输和数据副本的有效性产生影响。后者需要中断镜像进程，并检查本地和远程数据集的一致性，这个过程将十分频繁。

将注意力放到云端

如果您的备份目标在云端，你需要确切的知道该服务的具体位置。云可以提供顶级的线上SLA服务用于灾难恢复，但是与供应商的交付能力有关，距离上会有很多工作要做。

你不应该在概率或灾难事件的频率上欺骗自己。为5%做准备，你也能够应付其他的95%。

在一方面，如果DR即服务（DRaaS）通过城域网提供访问，例如通过SONET或MPLS，问一下自己，这个距离是否是一个有效的距离，从而避免被同样的灾难击中自己—这是否是一个全程停电或者100千米或更大伤害半径的飓风。如果DRaaS供应商就在街对面的大楼上，您的数据将不会是安全的。

另一方面，如果云服务是相当远距离的，并且通过广域网（WAN）访问，它有可能或可能不适用于复制事务性数据，对由延迟引入的“增量”或差异敏感。这种情况同样适用于简单的故障转移方案，以及涉及到相互依存的系统更复杂的故障切换模式。

在每种情况下，测试是需要的。所以，你的战略应该利用计划内和特设的测试本身。许多所谓的DRaaS服务真的是“DR作为事后诸葛亮”-提供DR的托管服务提供商并没有真正理解它需要什么额外的菜单选项。有许多软件供应商正在开发“令人垂涎的”前端菜单进行备份或镜像软件，它可以通过云界面呈现给用户。只是将复杂的数据保护软件可以通过Web界面呈现并不意味着供应商知道任何关于中DR / BC计划实际计划，或者是能够做好提供一个有效的连续性能力的工作。

底线：DR/ BC计划仍然是一个艰巨的任务，如果企业要生存，它们就必须明白，可能只占5％中断的中断事件就会造成100%的金融灾难。你不应该在概率或灾难事件的频率上欺骗自己。为5％做准备，你也将能够应付其他95％。