科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道定期测试灾难恢复计划

定期测试灾难恢复计划

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

对灾难恢复计划进行定期的测试被我们中间很多人当作了想当然的事情。我们制定了灾难恢复解决方案,获得了所需的硬件和软件,配置了系统,然后确保所有的备份和复制方案都已经到位。

作者:TechRepublic.com 2007年3月2日

关键字:

  • 评论
  • 分享微博
  • 分享邮件
本文译自TechRepublic,未经许可请勿转载

对灾难恢复计划进行定期的测试被我们中间很多人当作了想当然的事情。我们制定了灾难恢复解决方案,获得了所需的硬件和软件,配置了系统,然后确保所有的备份和复制方案都已经到位。

然后我们测试故障转移和灾难恢复响应系统,以确保一切都会按照我们计划的方式来运行。但是在经过初期的测试之后,我们中的大多数都遗忘这些系统,并(想当然地)认为一切都会在需要的时候(正常)工作。

但是,大多数机构都不会一成不变。它们会部署新的硬件和软件,它们会雇用具有不同技术类型和技术水平的新员工。

在很多情况下,建立(故障恢复)系统的人员最终会离开,并把灾难恢复计划留在和这些系统毫不相关的人员手里。尽管你可以培训新的人员并为了保持兼容性而检测新的设备,但是还是无法保证你的灾难恢复计划会按预计方式的持续工作。

这就是为什么你必须定期地不断测试它的原因。但是,你如何才能够确保自己正在测试正确的部分呢?你如何才能够确保自己进行了足够的测试,而同时不能过多地中断商业运行呢?

在某些情况下,管理你所在行业的规章制度会规定你必须测试什么,以及多长时间进行一次测试。例如,很多金融机构都有规定,要求每年至少进行一次灾难恢复系统的测试,而且要求在测试的过程当中,雇员要进行会在真实商业情况下发生的交易操作。

很多这类规章制度的一个缺点是,它们没有明确指出机构应该如何进行这些测试。所以你必须为这一目的设计自己的内部策略。

如果你没有规章制度需要遵循,或者如果规章制度不够明确,无法满足你的要求,那么公司就要自己确定应该如何进行测试,以及测试什么。有很多可能的方式,但是下面是三个常见的测试方案。

  • 隔离测试:将灾难恢复系统同网络的其他部分隔离开来,然后为测试而安装一些新的客户机。这就让你能够顺利测试灾难恢复系统而不需要影响生产。在测试结束的时候,重新进行镜像操作,或者干脆就用来自生产系统的真实数据覆盖掉测试数据,这就能够确保你已经为下一次测试或者真正的灾难准备好了。
  • 用测试数据进行真实测试:在没有生产交易发生的时候,真的让灾难恢复系统进行故障转移操作。然后,处理测试交易。最后,在测试结束之后用来自真实系统的生产数据覆盖掉灾难恢复系统(里的测试数据)。
  • 用真实数据进行真实测试:这是测试程序中最棘手的。把你的整个企业都故障转移到灾难恢复系统上,在生产期间内进行一段时间的真实交易处理。在完成测试之后,从灾难恢复系统上把数据恢复到生产系统上,并恢复生产系统上的活动。

你要进行什么类型的测试取决于你的内部规章制度,但是上述三种类型至少让你可以确定——灾难恢复系统能够进行你希望它们采取的行动。如果没有定期进行测试,那么就可能有一个或者更多的系统无法再在灾难恢复中心里运行,当你认为你很安全的时候,这会造成一场全新的灾难。


本文作者: Mike Talon是一位IT顾问兼自由记者,他曾经为传统的商业和新兴的网络公司工作过。


责任编辑:李宁

欢迎评论投稿
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章