制订灾难恢复方案时，一般我们遵循以下步骤。
1） 按照一定的顺序询问特定的问题
按照一定的顺序，询问一系列与商业灾备需求相关的问题，通过这些问题，可以确定灾备方案的基本环境、基础构件及期望的恢复时间。以下提供一些基本的问题，部分问题答案的给出需要基于风险评估和商业影响的分析。另外一些问题则需要运营部分基于其IT基础架构给出答案：
a) 哪个或哪些应用需要恢复？
b) 应用运行的平台是哪些平台？
c) 期望的RTO是什么？
d) 灾备实施场所之间的距离？
e) 连通方式，或者在灾备地点传输数据的基础架构的传输方式是什么？带宽是多少？
f) 有没有特殊的硬件和软件的配置需要恢复？
g) RPO是什么？
h) 需要恢复的数据量有多少？
i) 期望的灾难恢复层次（计划/未计划/交易集成）？
j) 谁来设计灾备方案？
k) 谁来实施灾备方案？
以上并不是所有可能的问题，但这是一个很好的开始，你可以设计其他一些问题，这些问题是如何使用的呢？参考下图：
以上模型称为沙漏模型，在沙漏瓶颈以上的问题定义了基本的业务和IT需求，这些基本的问题必须有充分的答复，因为任何问题的缺少都意味着我们要投资的方案可能会没有正确的评估。采用这样的方式，在灾备方案实施前可确保收集到正确的业务和IT基础架构的需求。
我们必须保证这些问题的答案已经广泛征求了企业管理部门、商务部门、应用组合IT维护组的意见。
2)
使用层/RTO（Tier/RTO）和恢复的层次定位灾备方案的子集
现在我们可以定义初步的方案，注意：在灾难恢复的七层中，一层总是建立在前一层的基础之上。对应于计划停机、非计划停机和交易一致性，相应的灾备技术和方案也有所不同：
§
计划停机：这一方案只有助于计划中的停机或者数据移植，对非计划的停机没有作用。
§
非计划停机：在硬件和数据一致性的层面，这一方案有助于非计划停机的恢复，也意味着支持计划停机。在应用和数据库层面，这一层次的恢复不支持交易一致性的恢复。
§
交易一致性：对于非计划的停机，方案要求在应用和数据库交易一致性的层面提供恢复的能力。这一方案隐性要求硬件层次支持计划停机和非计划停机。
确定了合适的恢复层次、结合RTO、参考下图，可以很快的确定需要的灾难恢复方案。
3)
排除非方案的东西
现在我们通过把第一步中收集到的问题答案应用于候选的方案并剔除不合适的方案，来定义初步、候选的灾难恢复方案。请参考下图：
通过第一步中获得的问题答案，如距离、不支持的平台等，可以剔除不符合要求的方案。
如果在这一步骤完成后存在多个灾备方案，这都是正常的，它们都是可用的方案。
4)
将确定的方案提交给评估组
经过第三步后，将一组初步的灾备方案和可用的技术提交给资深的评估组，这个组由一些资深的成员组成。他们将详细的比较和分析这些备选方案，同时对有效的候选方案注明所需要的技能。
评估组需要充分详细的配置每一个候选方案。最后，评估组将决定最终选择最合适的灾备方案。
收起