灾难恢复（DR）即服务，或基于云的灾难恢复，使得测试灾难恢复解决方案变得如此简单，几乎可以忽略不计。与传统的自我管理的有效业务连续性/灾难恢复(BC/DR)规划相比，灾难恢复即服务或云灾难恢复(DR)使测试DR计划变得如此简单，几乎可以忽略不计。大多数业务连续性/灾难恢复(BC/DR)计划的一个主要障碍是需要重复测试以确保系统在发生灾难时准备就绪并证明符合组织的法规要求。使备份系统上线的复杂性不仅使测试任务本身变得困难，更重要的是，如果在没有适当准备的情况下进行，可能会影响原用户使用的服务器。当被问及DR测试周期的频率时，ESGResearch回应说，根据每周对他们从重大中断中恢复和恢复的能力进行的测试，那些使用组织的云灾难恢复服务的测试频率是使用自我管理的组织的4倍BC/DR解决方案（20%对5%）。这种测试频率的比较源于几个关键因素。大多数服务提供商不只是提供“只为您使用的东西付费”，有时还包括一些折扣和无DR测试津贴。无论哪种方式，只需要在备份存储资源上花费最少的钱，并且可以在数小时或数天的基础上增加一点点消耗的CPU资源，从而使测试在经济上可行——而不是使用传统的更昂贵的流程与BC/DR服务提供商或自我管理的BC/DR站点相关联。现代灾难恢复即服务(DRaaS)解决方案通常包括“沙盒”或分区虚拟机的能力，以便可以在不影响生产环境的情况下完成测试。在典型的本地解决方案中，使用传统虚拟化管理工具进行沙盒处理通常要困难得多，但大多数DRaaS提供的这被视为“桌面优势”或基本功能要求。结合这些因素，坦率地说，故障转移准备测试是如此简单，以至于它必须在大多数DRaaS解决方案中完成，这与传统的自我管理BC/DR设施的测试限制正好相反。另一方面，考虑到DRaaS的易测试性，甚至可以制定一些基本的测试要求，每个BC/DR解决方案都必须通过。根据相同的ESGResearch调查结果，每年有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
