灾难恢复测试
制定 灾难恢复(DR)计划 后,定期对计划进行测试。 您可以避免在面对实际灾难时发现缺陷。 测试有助于确保计划行之有效,并达到您想要的结果。 如果计划在测试过程中不起作用,可以进行必要的修改。 定期测试有助于确保捕捉到工作环境中的任何变化,并在必要时进行调整。
为了验证您的计划,请使用不同类型的灾难恢复测试:
- DR 干测试
- DR 模拟
- 切换
DR 干测试
模拟测试是对灾难恢复计划进行纸质练习。 在进行干测试时,您不会执行任何恢复操作,但会检查计划中是否存在明显漏洞。 例如,干燥测试有助于确保:
- 有合适的人员参与
- 备份存在且可用
- 人员之间的沟通渠道有效
- DR 运行本中没有缺失的步骤
- 团队之间的交接工作高效进行
DR 干测试与其他测试一样,需要在技能和人员方面付出同样的努力。 由于不执行实际的恢复操作,这种类型的测试速度较快,因此与其他测试类型相比,通常运行频率较高。 您可以选择是测试整个计划,还是测试其中的个别部分和服务。
DR 模拟
灾难恢复模拟是一种验证或审计应急运行手册的方法,通过模拟真实紧急情况和恢复数据,检查解决方案提供的 恢复时间目标在灾难恢复计划中,指灾难发生后业务流程恢复所需的时间。 (RTO) 和 恢复点目标在灾难恢复计划中,数据恢复的时间以秒、分、小时为单位,从恢复的实例开始,到灾难发生点结束。 (RPO)。
灾难恢复模拟需要仔细规划,因为在避免对生产工作负载造成影响的同时,还要对主区域的数据复制引入潜在的中断。 在测试灾难恢复环境时,它可能暂时无法用于实际的灾难恢复目的。 这种风险取决于具体的云服务及其部署方式。 有些服务可能允许同时进行测试和提供服务,有些则不允许。
灾难恢复模拟在指定的灾难恢复区域创建生产环境的临时副本,用于测试和验证。 模拟结束后,测试环境将被删除或重置,测试期间所做的任何更改都将被丢弃,因为主生产环境将继续正常运行。
切换
切换涉及将生产环境从一个区域切换到另一个区域。 这种方法有助于验证和审计在替代区域长期运行和维持生产运营的能力。 生产运行会在第一个区域平稳停止,然后切换到第二个区域,并在可能需要恢复数据后重新启动。
验证第二个区域是否按预期运行后,就可以恢复生产活动,并配置数据复制,将原始区域作为新的辅助区域。 您的生产环境将继续从该站点运行,直到您决定再次切换回来。
DR 测试频率
多久测试一次灾难恢复计划取决于很多因素,包括法规遵从标准的要求。 如果合规性不是问题,则应争取每年至少进行一次全面的灾难恢复测试,并将结果记录在案,供审计人员审查。 全年进行小规模测试以帮助确保准备就绪是一个很好的做法。
考虑以下问题并调整测试频率:
- 我的工作量有多大变化?
- 工作量变化越大,就越需要经常进行某种形式的灾难恢复测试。 这样,您就可以确认这些更改不会影响您的恢复能力。 变化可能包括新的依赖关系、其他云服务、基础设施变化等。 不断增长的数据集需要更长的恢复时间,这可能会影响您满足特定 RTO 的能力。
- 我的人员编制有多活跃?
- 在测试频率方面,您还可以考虑人员更替。 如果执行恢复的工作人员发生变化,应确保团队的新成员了解灾难恢复的工作方式及其在灾难恢复计划中的作用。 如果您有几位不确定或不熟悉灾难恢复测试的新团队成员,就会给您的恢复计划增加风险。
我的测试还应该关注什么?
任何灾难恢复测试的首要目标都是确认您可以成功恢复工作负载。 不过,要确保以下方面也能很好地发挥作用:
- 关键人员:灾难恢复计划应概述成功恢复所需的人员及其职责。 考虑在测试过程中是否需要更多的人员或角色,或者是否有些人超出了要求,以及人员履行职责的能力如何。
- 沟通:灾难恢复计划必须明确概述灾难发生时的沟通方式。 考虑测试期间参与者之间的沟通效果,包括所使用的沟通渠道。
- 记录依赖关系:您的灾难恢复计划可能概述了依赖关系。 检查这些信息是否有效,并且不会妨碍恢复过程。 同时,确保记录任何新的依赖关系。
- 其他文档:运行手册可能用于实施恢复,因此了解其准确性和有效性非常重要。 记录步骤不足会导致延误,而提供过多细节或不相关的细节可能会产生同样的效果。 让作者以外的其他人测试这些步骤,以确保它们清晰明了。 这样,即使在灾难期间作者不在,程序也可以使用。
测试后
完成任何测试后,记录测试结果,作为下一次测试的基准。 如果以后改变了测试程序,就很容易比较结果了。
每次灾难恢复测试后,根据结果更新计划和相关文档。 灾难恢复计划是一份活的文件,需要定期调整才能保持有效。 利用参与者的反馈意见来确定哪些有效,哪些无效,并将这些见解纳入今后的测试中。 此外,如有需要,可考虑提供更多培训,无论是明确职责、加强沟通还是提高技术技能。