灾难恢复(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调查结果显示，令人沮丧的是，每年丧的是DRaaS9%独立管理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