制定灾难恢复计划的最佳实践或资源？[关闭]

我的任务是领导一个项目，该项目涉及更新旧的，有些荒谬的灾难恢复计划。目前，我们只是在寻找DR的IT方面。他们最后一次这样做是通过组成一次灾难（数据中心被洪水淹没）并进行规划以排除所有其他灾难类型来设置范围。我想采取更全面的方法。我知道这是一个已解决的问题，其他组织也已编写了灾难恢复计划。

我们的计划是采纳我们的IT DR计划并继续前进，然后说：“嘿，这是我们在IT的DR计划中想要的，它与大学的其余部分保持一致吗？您是否已恢复服务优先级？想改变吗？” 我们有一个很好的主意，该计划的其余部分是什么，我们希望这一计划能顺利进行。

我正在寻找的是有关如何确定灾难恢复计划范围以及应该考虑哪些问题的指南。您是否有与DR计划开发相关的最喜欢的资源，书籍，培训？

的信息的极好来源是灾难恢复杂志（约）。

可用的社区资源包括其“通用惯例”（GAP）文档的当前草案，该草案很好地概述了构成可靠的业务连续性计划和流程的流程和可交付成果。还提供了涵盖各种DR / BC主题的几本白皮书。

该过程似乎令人生畏，但是如果系统地对最终目标进行概述（例如DRJ GAP文档），则可以确保优化投资时间并最大程度地提高最终产品的价值。

我发现他们的季度出版物也很有趣且内容丰富（请订阅）。

确保您有紧急联系人名单。 又名召回名册

它看起来应该像一棵树，并显示谁与谁联系。在分支机构的末尾，最后一个人应呼叫第一个，并报告任何无法联系的人。

（可以通过人力资源协调，用于任何类型的灾难）

如果我们添加我们的想法，那么每个人都添加了他们自己的想法后，我们可以从这篇文章创建一个不错的Wiki。我知道还有很多事情要跟着做，但是在恢复方面，我们中的一些人有特定的优先事项。首先，这是我的：

确保您拥有网络的离线/远程文档

使用灾难恢复，最基本的就是您的RTO（恢复时间目标）和RPO（恢复点目标），它们大致翻译为“必须花费多少时间才能收回它，以及我们可以损失多少数据”。在理想的世界中，答案将是“无和无”，但是DR场景是一种特殊情况。这些确实应该由您的客户驱动，但是由于您是从IT角度出发的，因此您可以做出最佳猜测，但可以根据需要进行调整。力争尽可能接近“无和无”的目标是好的，但是您需要能够识别出收益递减点何时到达。

这两个因素在一年中的不同时间可能不同，在不同的系统上也可能不同。

我喜欢更全面的方法；列出可能导致灾难恢复场景的事件很诱人，但这些事件实际上更多地属于风险分析/缓解活动。对于灾难恢复，该事件已经发生，并且事件的相关性不那么重要（可能在影响灾难恢复设施的可用性方面除外）。如果您丢失了服务器，则无论它是否被闪电击中，意外格式化或其他原因，都需要将其取回。着重于灾难的规模和扩散的方法更可能产生结果。

如果您发现客户不愿参与其中，则可用于客户的一种方法是从非IT角度询问客户灾难恢复问题。询问他们的计划是什么，如果他们所有的纸质文件都燃烧起来就是一个例子。这有助于使他们更多地参与更广泛的灾难恢复，并可以将有用的信息提供给您自己的计划。

最终，定期测试计划对成功至关重要。有一个漂亮的DR计划在纸上看起来不错，但不能满足其目标，这不好。

实际上，作为第一步，“单事件”开发模型是一个好主意。原因之一是使计划工作更加现实和集中。一路规划洪水。然后假设发生另一种事件（例如，长期停电），对该计划应用该计划，并解决发生的故障。经过几次迭代后，该计划应相对稳健。

一些想法...-一定要考虑没有人。如果发生洪水，您不能假定所有相关人员都在岗。某人可能正在度假，受伤或与家人打交道。
-计划沟通问题和弱点。有多个数字和多种模式。
-DR计划需要一连串的命令。了解谁做出决定至关重要。
-该计划需要广泛分发，包括异地和离网。灾难期间需要访问它！

在过去的两年中，我一直在从事大型DR测试的工作。我们发现在“现实”的情况下测试我们的服务，人员和流程非常有用。一些经验教训（也许很明显），希望对您有所帮助：

• 尽管未经测试的服务已在灾难恢复文档中编写了内容，但它们通常具有隐式的，诱发灾难的依赖性。通过一两次现实的测试将它们淘汰掉是灾难恢复准备过程的有用且可衡量的输出。
• 未经测试的人往往认为他们的系统还可以，并且在灾难情况下会“知道该怎么办”。他们摇晃起来了真实的测试或两个是伟大的。
• 未经测试的过程在实际紧急情况下会迅速瓦解。特别是，复杂的升级流程主要集中在以惊人的方式通知高层管理人员中断。轻量级流程着重于运营人员和其他响应者的需求，有关不断发展的紧急情况，明确的责任转移和“日常”紧急响应程序的中央信息源，效果最佳。

我想我要讲的是，您应该尽量不要使有关灾难恢复计划流程的所有事情成为理论上的。推动获得许可以实际破坏事物，从而获得有关组织准备情况的可靠数据。当然，这将需要管理层的一些认真的支持，但是对于企业来说，花几天的时间进行真正的最糟糕的排练可能是一个很好的重点。

ian

英国标准协会（BSi）提供了几项专注于连续性管理和灾难恢复的标准。

• BS 25999-1：2006业务连续性管理，第1部分：业务守则
• BS 25999-2：2007业务连续性管理。规格
• BS 25777：2008 信息和通信技术连续性管理。实务守则

看起来似乎很明显，但是要与上面的非现场文档一起使用，请确保您具有非现场（最好是不在该区域内）备份。这可以是在线存储服务，也可以是将磁带带到的地方。

我之所以说最好是在该地区之外，是因为我来自一个每年自然灾害不多的地区，但是，如果/当我们确实发生自然灾害时，那是一个大规模毁灭（地震，火山）的区域性规模。最好将您的备份放在银行的保险箱中，直到您的银行处于液态岩浆之下（/ Dr。Evil Voice）。

我已经读到的一件事是，各机构分担了在大型站点遭受攻击时维护热点站点的成本。他们制定了计划，使用虚拟化等来恢复两家公司对热点站点至关重要的任务，然后在确保所有指示灯均闪烁的水平上共享人员。只是一个想法。

对于书籍，有乔恩·威廉·托伊戈（Jon William Toigo）撰写的《灾难恢复计划》（Disaster Recovery Planning），现在已是第3版，即将推出第4版 blook（博客+书）。

劳拉

这是SQLServerPedia的链接，给出了DR的基础知识。

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

另请阅读“业务连续性”