灾难恢复即服务 将DR希望转为具体策划
发布时间：2022-05-24 12:29:33 所属栏目：云计算 来源：互联网
导读：灾难恢复(DR)即服务，或者又称为基于云的灾难恢复，使得测试一个DR方案变得容易到几乎可以忽略的地步。 与传统的自主管理的有效业务连续性/灾难恢复（BC/DR）规划相反，灾难恢复即服务或云计算灾难恢复(DR)使得测试一个DR计划变得容易到几乎可以忽略的程度。
|
灾难恢复(DR)即服务，或者又称为基于云的灾难恢复，使得测试一个DR方案变得容易到几乎可以忽略的地步。 与传统的自主管理的有效业务连续性/灾难恢复（BC/DR）规划相反，灾难恢复即服务或云计算灾难恢复(DR)使得测试一个DR计划变得容易到几乎可以忽略的程度。 大多数业务连续性/灾难恢复(BC/DR)规划的一个主要障碍是必须进行重复性的测试，以此来确保当灾难发生时系统的防备能力和证明符合有管理法规要求的组织的规范。将备用系统上线的复杂性，不仅仅造成测试任务本身的艰巨，更重要的是如果在没有适当准备的前提下进行的话可能会影响到原本用户正在使用的那些服务器。 结合这些因素，非常坦率的说，故障转移的防备性测试在大多数的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也许就是最适合你的答案。 （编辑：厦门站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐