业务影响分析
创建全面的灾难恢复计划始于业务影响分析。 执行此分析时，将创建一系列详细的灾难场景，以用于预测当某些业务流程中断时将遭受的损失的规模和范围。 例如，如果客户服务呼叫中心被火烧毁，该怎么办？ 或者，如果地震袭击了公司总部，又该怎么办？
这种分析可帮助确定最关键的业务领域和职能，并确定每一项关键职能可以忍受多长时间的中断。 掌握这些信息后，您就可以开始制定计划，确定如何在各种场景中确保最关键的运营不中断。
IT 灾难恢复规划应遵循并支持业务连续性规划。 例如，如果业务连续性计划要求客户服务代表在呼叫中心发生火灾后在家工作，那么需要哪些类型的硬件、软件和 IT 资源来支持这一计划？
风险分析
评估企业所面临风险的可能性和潜在后果也是灾难恢复规划的重要组成部分。 随着网络攻击和勒索软件变得越来越普遍，了解当今所有企业面临的一般网络安全风险以及所在行业和地理位置的特定风险就变得至关重要。
您需要针对各种场景（包括自然灾害、设备故障、内部威胁、蓄意破坏和员工错误）评估风险，并考虑对企业的整体影响。 可以自己回答以下问题：
由于错失销售商机或创收活动被中断，将会遭受哪些财务损失？
品牌声誉会受到哪些损害？ 客户满意度会受到怎样的影响？
员工工作效率会受到怎样的影响？ 可能会损失多少工时？
该事故可能给员工健康或安全带来哪些风险？
是否会影响任何业务计划或目标的进展？ 如何影响？
划分应用的优先级
并非所有工作负载对于企业维持运营的能力都同样重要，某些应用中断带来的影响也比其他应用要小。 系统和应用可分为三层，具体取决于您可以忍受它们宕机的时间长短以及数据丢失的后果严重程度。
任务关键型： 应用的功能对于企业的生存至关重要。
重要： 您只能容忍应用宕机相对较短的时间。
非必要： 可暂时用人工流程取代宕机的应用，或暂时离开这些应用也没多大关系。
记录依赖关系
灾难恢复规划的下一步是创建硬件和软件资产的完整清单。 在此阶段了解关键应用的相互依赖关系至关重要。 如果一个软件应用出现故障，其他哪些软件应用也会受到影响？
在最初构建系统时设计弹性和灾难恢复模型是管理应用相互依赖关系的最佳方法。 在当今基于 微服务的架构中，当其他系统或流程出现故障时查找无法启动的流程是一件很常见的事情，反之亦然。 从此类情况进行恢复有一定的难度，如果您有足够的时间为系统和流程制定备用计划，那么在实际灾难发生之前提前发现此类问题至关重要。
制定恢复时间目标、恢复点目标和恢复一致性目标
通过考虑所面临的风险并且执行业务影响分析，您应当能够确定恢复系统所需的时间、可以继续使用的数据量以及可以容忍的数据损坏或偏差程度。
恢复时间目标 (RTO) 是指在服务中断后使应用或系统恢复正常运行所需的最长时间。
恢复点目标 (RPO) 是指使企业恢复正常运营而必须恢复的数据的最长时间长度。 对于某些企业来说，即使丢失几分钟的数据也可能是灾难性的，而另一些行业的企业则也许能够容忍更长时间长度的数据丢失。
在服务级别协议 (SLA) 中为持续数据保护服务建立恢复一致性目标 (RCO)。 RCO 指标表示在灾难恢复情况下，在已恢复的流程或系统的业务数据中可以容忍有多少个不一致的条目，因此它描述的是复杂应用环境中的业务数据完整性。
监管合规问题
企业建立的所有灾难恢复软件和解决方案都必须满足任何强制性的数据保护和安全要求。 这意味着，所有数据备份和故障转移系统的设计都必须符合主系统所遵循的相同标准，从而确保数据保密性和完整性。
同时，多项监管标准都规定，所有企业均必须保持灾难恢复计划和/或业务连续性计划。 例如，萨班斯-奥克斯利法案 (SOX) 要求美国的所有上市公司将所有业务记录的副本至少保留五年。 如果未遵守此规定（包括未建立和测试适当的数据备份系统），可能会导致公司遭受重大经济处罚，甚至导致其领导者入狱。
选择技术
备份是制定任何可靠灾难恢复计划的基础。 过去，大多数企业都是依靠磁带和磁盘 (HDD) 进行备份，保持数据的多个副本并在异地位置至少存储一个副本。
在当今的永续数字化转型环境中，异地存储库中的磁带备份通常无法满足维持关键业务运营所需的 RTO。 设计自己的灾难恢复解决方案包括复制生产环境的多项功能，并且需要承担用于支持人员、管理、设施和基础架构的费用。 因此，许多组织都寻求基于云的备份解决方案或全面的灾难恢复即服务 (DRaaS) 提供商的帮助。
选择恢复地点位置
构建自己的灾难恢复 数据中心 涉及平衡多个相互冲突的目标。 一方面，应将数据副本存储在距离公司总部或办公地点足够远的地方，这样它就不会受到与主要业务地点相同的地震事件、环境威胁或其他危险的影响。 另一方面，异地存储的备份总是比主要业务地点中的本地备份需要更长的时间来恢复，并且网络延迟也会随距离延长而增大。
持续测试和审查
简而言之，如果灾难恢复计划没有经过测试，就不能认定为可靠。 所有承担相关责任的员工都应该参加灾难恢复测试练习，这可能包括在故障转移地点保持运营一段时间。
如果执行全面灾难恢复测试超出了贵组织的预算或能力，您也可以安排测试过程的"桌面模拟"演习，但必须明白，与完整的测试相比，这种测试不太可能揭示 DR 过程中的异常或弱点（尤其是判断是否存在之前未发现的应用相互依赖关系）。
由于硬件和软件资产可能会随着时间的推移而发生变化，因此必须确保灾难恢复计划也与时俱进。 您应当定期审查和修订该计划。
IBM Knowledge Center 提供了一个 灾难恢复计划示例。