“灾难恢复即服务”将DR希望转为具体计划

灾难恢复(DR)即服务，或者又称为基于云的灾难恢复，使得测试一个DR方案变得容易到几乎可以忽略的地步。

与传统的自主管理的有效业务连续性/灾难恢复（BC/DR）规划相反，灾难恢复即服务或云计算灾难恢复(DR)使得测试一个DR计划变得容易到几乎可以忽略的程度。

大多数业务连续性/灾难恢复(BC/DR)规划的一个主要障碍是必须进行重复性的测试，以此来确保当灾难发生时系统的防备能力和证明符合有管理法规要求的组织的规范。将备用系统上线的复杂性，不仅仅造成测试任务本身的艰巨，更重要的是如果在没有适当准备的前提下进行的话可能会影响到原本用户正在使用的那些服务器。

当被问到DR测试的周期频率时，ESG Research的回应是，在每周进行的从一次重大停电事故中能否顺利恢复和恢复的速度有多快的测试来看，那些使用云灾难恢复服务的组织的测试频率是使用自主管理的BC/DR解决方案的测试频率的4倍（20% 对比 5%）。这个测试频率的对比结果源于几个关键因素。

大部分服务提供商不仅仅提供“只支付您使用的”，有时候还包括一些折扣和免DR测试的特权。无论哪种方式，都只需要花最少的钱在后备的存储资源上，然后只要在几小时或者几天的基础上增加一点消耗的CPU资源，这使得测试变得经济可行—而不是使用传统的BC/DR服务提供商或者自主管理的BC/DR站点相关的更昂贵的流程。

现代的灾难恢复即服务（DRaaS）解决方案通常包括“沙箱”的能力或者对虚拟机进行分区，这样测试可以在不影响产品环境的条件下进行。典型的本地部署解决方案中通过传统的虚拟化管理工具实现沙箱化通常会困难很多，然而大部分的DRaaS都提供这种被认为是“桌面上的利益”或者一个最基本的功能需求。

结合这些因素，非常坦率的说，故障转移的防备性测试在大多数的DRaaS方案中简单到必须要做，这恰恰和传统的自主管理的BC/DR设施的测试限制完全相反。在另一方面来说，考虑到DRaaS的易于测试性，甚至可以制定一些让每一个BC/DR方案都必须通过的测试基本要求。根据同样的ESG Research的调查结果显示，令人沮丧的是每年有15%的DRaaS和9%的自主管理的BC/DR方案没有经过测试。

复制功能不是BC/DR解决方案

不管你是否更青睐DRaaS还是自主的BC/DR， 有一点需要注意的是，在你的存储系统里的复制技术或者备份软件并不是一个真正的BC/DR的解决方案。复制只是一种数据转移技术，能够提供给BC/DR方案所需要的IT资源。真正的BC/DR产品和功能包括对BC/DR计划的制定开发，测试的编排，以及资源的故障转移到备份站点的管理。BC/DR更多的是关于了解关键性系统故障对业务造成的影响，文档化整个恢复的过程，进而影响到现有的关于测试和防备性的企业文化。也就是说，对于大部分企业组织，如果你没有将数据和主要的系统进行复制，那么你的BC/DR计划的其余部分就只是空谈。

没有测试，你只有BC/DR希望而没有计划

如果你没有至少在每个季度测试每一个关键系统的恢复能力，那么请你开始这么做，否则你几乎可以肯定的发现那些系统没有你所想的那样有弹性（当你最需要他们的时候）。对那些还在努力的维护着一个自主的BC/DR方案或者对此进行常规性测试的人，DRaaS也许就是最适合你的答案。

不管是自主的BC/DR还是DRaaS，最重要的是要记住***的BC/DR测试是那种会失败的即使只是部分的，因为这样你就知道哪些需要改进。如果你的BC/DR测试的结果是一概的全部通过，那么有两种可能，你要么拥有一个被很好的部署和管理的当今市场上最***的BC/DR方案，或者（更多的可能是）你的测试还不够彻底。

如果你不对你的BC/DR方案进行常规的测试，那么你就不算拥有一个BC/DR的规划，你只有一个BC/DR的希望。随着虚拟化技术将服务器变得便携，使用DRaaS方案来提供备用站点很有成本效益，同时拥有编排服务恢复的可管理性，BC/DR不再只是一个希望或者一个计划，而能够真正变成任何规模的组织都能够达成的目标。

原文出自：http://www.searchcloudcomputing.com.cn/showcontent_85977.htm