我负责领导一个关于更新旧有的灾难恢复计划的项目。 现在我们只是想把DR的IT方面整理出来。 上一次他们这样做时，他们设定了一个单一的灾难（数据中心被洪水淹没），并计划排除所有其他灾难types。 我想采取更全面的方法。 我知道这是一个解决的问题，其他组织已经制定了灾难恢复计划。
我们的计划是采取我们的IT灾难恢复计划，然后继续说：“嘿，这是我们在IT灾难恢复计划中所需要的，是否与大学的其他部分相匹配？是否有恢复服务的重要性我想改变一下吗？“ 我们有一个很好的主意，其余的计划是什么，我们期待这样的结果。
我正在寻找的是如何规划灾难恢复计划的指导以及我应该考虑的问题。 您是否拥有与灾难恢复计划发展相关的资源，书籍和培训？
一个很好的信息来源是“ 灾难恢复期刊” （ 约 ）。
可用的社区资源包括当前的通用实践（GAP）文件草案，该文件提供了构成坚实业务连续性计划和stream程的过程和可交付成果的极好概述。 还有几个白皮书，涵盖各种DR / BC主题。
这个过程似乎令人望而生畏，但是如果系统地处理好最终结果（比如DRJ GAP文件），您可以确保优化投入的时间并最大限度地提高最终产品的价值。
我觉得他们的季度刊物也很有趣，也很有信息（ 订阅 ）。
确保你有一个紧急联络名单。 又名召回名册
它应该看起来像一棵树，并显示谁联系谁。 在分支结束时，最后一个人应该打电话给第一个人，并报告任何不能联系的人。
（这可以通过人力资源协调，并用于任何types的灾难）
如果我们添加我们的想法，我们可以创build一个很好的维基从这个post中，每个人都添加了自己的想法。 我知道那里有一群人需要关注，但我们中的一些人在恢复方面有特别的优先考虑。 开始，这是我的：
有了DR，基本的事情就是您的RTO（恢复时间目标）和RPO（恢复点目标），这大致转化为“需要花费多less时间才能获得回报，以及可以承受多less数据丢失”。 在一个理想的世界里，答案将是“无与无”，但是DR情景是一个例外的情况。 这些确实应该由你的客户来推动，但是由于你从ITangular度出发，你可以做出最好的猜测，但是可以根据需要做好准备。 为了尽可能地接近“无和没有”，你可以合理地得到好的结果，但是当收益递减点到来的时候，你需要能够认识到这一点。
这两个因素在一年的不同时间可能会有所不同，而在不同的系统上可能会有所不同。
我喜欢更全面的方法; 列出可能导致灾难恢复情况的事件是很有诱惑力的，但这些更多地属于风险分析/缓解工作。 有了灾难恢复事件，事情已经发生了，具体情况不太相关（除了影响DR设施的可用性）。 如果你丢失了一台服务器，你需要把它拿回来，不pipe它是否被雷击，意外格式化，或者其他。 围绕灾难规模和蔓延的方法更有可能产生结果。
如果您发现客户不愿意参与其中，一种使用客户的方法是从非ITangular度向他们提出DR问题。 如果他们所有的纸质文件都火上加油，就问他们的计划是否就是一个例子。 这可以帮助他们更多地参与到更广泛的DR事件中，并可以将有用的信息input到自己的计划中。
最后定期testing你的计划是成功的关键。 有一个美丽的DR计划，在纸上看起来不错，但不符合它的目标是不好的。
其实，“单一事件”发展模式是一个好主意，作为第一步。 其中一个原因就是使得规划工作更加现实和重点突出。 一路计划洪水。 然后假设一个不同的事件（比如说长期的停电），把这个计划应用到这个计划中，并且确定什么是rest时间。 经过几次迭代，计划应该是相对强大的。
有些想法… – 一定要说明不可用的人。 如果发生洪水，你不能认为所有相关人员都可用。 有人可能正在度假，受伤或与家人打交道。
– 计划沟通问题和弱点。 有多个数字和多种模式。
DR计划需要一个命令链。 知道谁做决定是至关重要的。
– 该计划需要广泛分布，包括异地和离网。 它需要在灾难期间访问！
我在哪里工作，在过去的两年里，我都参与过大规模的灾难恢复testing。 我们发现，在“现实”情况下testing我们的服务，人员和stream程非常有用。 一些经验教训（或许是显而易见的），希望你觉得它们有用：
我想我得到的是你应该尽量不要把你的灾难恢复规划过程的一切理论化。 推动许可实际上破坏事情，从而获得关于你的组织准备的硬数据。 当然，这需要pipe理层提供一些严肃的支持，但是，如果真的把精力集中在业务上，可以花几天时间进行最差的排练。
奇安
英国标准协会 （BSi）有几个重点关注连续性pipe理和灾难恢复的标准。
这看起来很明显，但要与上面的非现场文档一起，请确保您有非现场（最好在该地区以外）的备份。 这可能是一个在线存储服务或一个地方去拿磁带。
我最好说这个地区，因为我来自一个每年没有多less自然灾害的地区，但是如果/当我们有一个地区时，这个地区就是一个大规模破坏（地震，火山）的地区性规模。 把你的备份放在银行的保险箱里，直到你的银行处于液态热岩浆状态（/ Evil Voice博士）为止。
我已经读到的一些东西是代理机构分担维护一个热门网站的成本，因为这个网站的时间太长了。 他们制定了计划，使用虚拟化等方式恢复公司对热点站点至关重要的任务，然后在确保所有灯光闪烁的情况下共享人员。 只是一个想法。
对于书籍，Jon William Toigo的“ 灾难恢复计划” （现在已经是第三版）将在第四版 blook（博客+书籍）上出现。
劳拉，
这是一个来自SQLServerPedia的链接，它提供了DR的基础知识。
http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/
另请阅读“业务连续性”