面对灾难，首先要区分灾难的种类，然后有针对性地找出解决方案，实现更有效的数据恢复，保证数据安全。
根据影响定义灾难
灾难可以定义为任何不可预知的影响企业正常运营的事件（预知事件产生不可预知的影响也符合灾难定义）。我们最关注的是灾难对企业正常运营造成的影响，而不是灾难的性质。从灾难恢复的角度来看，灾难发生原因和灾难类型并不重要，真正重要的是灾难对企业正常运营产生的影响。灾难影响的定义包括：
- 范围??灾难影响到企业的哪些运营。
- 持续时间??灾难造成的企业不能正常运营的时间长度。
- 发生时间??企业不能正常运营与其他相关事件的时间关系。
灾难恢复旨在减轻灾难对企业运营带来的不良影响，而不管灾难发生的原因是什么。
范围
灾难对企业运营影响的范围可大可小，比如一个天文观测站，观测望远镜的调焦系统出现故障在某种意义上是一种灾难。如果这个观测站有两台或者更多的望远镜，由于具有冗余功能，观测工作仍能正常进行。然而，如果观测站仅有的一台望远镜或者调焦系统发生一定程度的故障，则该企业（天文观测站）的观测工作仍不能正常进行。
持续时间
灾难对企业运营最明显的影响是停机时间??指整个或局部企业不能正常运营的时间。故障时间（图1）是指企业不能正常运营的开始时间。T2是指企业从灾难中完全恢复的时间，停机时间是指T1和T2之间的时间间隔。
发生时间
一般来说，灾难造成的停机时间越短，企业的损失就越小。然而灾难的影响与灾难发生时间和灾难导致的停机时间有关。例如，在观测站的例子中，如果望远镜调焦系统发生故障的时间正好是彗星飞过地球的时间，则故障对观测站的影响要比白天或宇宙相对平静时发生故障的影响大得多。
灾难对信息服务的影响
灾难对企业信息服务的影响通常大于对企业运营其他方面的影响。举例来说，如果记录某些活动的服务器及其在线存储服务器同时在T1（图2）时间遭到灾难性破坏，灾难影响将从最近的日志备份时间T0（图2）持续到系统完全恢复时间T2（图2）。T0和T1之间记录的活动与在线存储一旦丢失，T1和T2之间的活动就未被记录，因为日志系统无法正常运行，生成日志。
灾难造成的影响还与企业所记录活动的程度密切相关。如果日志只是概念测试的部分记录，灾难影响可能无关紧要，因为测试还可以重新运行。然而，如果活动日志用来生成规范企业运作的报表或者用来处理客户订单，那么，灾难造成的损失将十分巨大。
准备工作和恢复计划
灾难恢复计划和准备通常遵循以下两种方法：
- 制定任何灾难随时发生的全面计划。
- 针对可能发生的每种灾难类型建立特定的灾难恢复计划库。
尽管笔者认为总体上第一种方法更可取，但本部分我们还是列举了这两种方法的优劣势。
全面灾难恢复计划
有些企业设计的全面灾难预防和恢复计划可以对任何可预见的灾难事件进行全部或部分的调用。这些计划与其说是灾难事件驱动，倒不如说是不得已而启动，它们一般根据能够预见的最坏灾难事件而设计。执行全面灾难恢复计划，必须采取的第一步是评估灾难影响，从而确定应当调用哪些团队和哪些资源。正因为如此，灾难发生和开始恢复之间，通常会有一段延时。
特定灾难恢复计划
与上述办法相反，有些企业制定了几套特定灾难恢复计划。这些计划考虑了最可能发生的灾难和灾难的最大潜在影响。这些企业列出了可能发生影响的不同灾难，同时考虑了这种灾难对整个行业、地区、产品、服务和供应链的影响。他们会采用历史信息和最好的假设方法对每一种灾难进行量化分析，并计划出最坏的和最有可能的影响。通过最详细的计划，他们会高度重视最有可能发生的灾难和具有最大潜在影响的灾难。
例如，在加利福尼亚和日本，发生地震的机率很高，所以建筑都设计成抗震建筑。而在新英格兰和伦敦，地震发生的机率很小，因此人们在防震上投入的精力就较小（但不能忽略发生地震的可能）。另一个例子就是以上几个地区几乎都没有防御龙卷风侵袭的措施。因为龙卷风在上述地区十分罕见。有些灾难独立于自然环境因素，绝大多数企业都具有紧急恢复计划，以应对电源中断、火灾、洪水、网络故障和其他不可预知的灾难。
执行特定灾难恢复计划，应当遵循特定的步骤和流程。只要灾难的性质清楚，就不需要在恢复初期做太多决策。多数情况下，初始恢复步骤可以自动完成。但特定灾难恢复计划的主要缺点是不能预料灾难，比如企业有可能采用电源中断应急方案来进行火山爆发灾难恢复。
混合恢复计划
实际上，大多数企业采用上述两种偏激方法的组合方案。即制定一些针对常见灾难（如断电、暴风雪等）的特定计划，同时特定全面恢复计划，应对其他所有灾难。此外，也有一些企业拥有多个全面恢复计划，以应对不同影响类型的灾难（例如一个计划应对某栋建筑被毁，另一个计划应对计算机系统大面积故障）。
企业通常倾向于采用能满足自身要求的恢复策略。根据笔者的经验，最佳的方案是一定要有一个可以应对各种灾难事件的全面恢复方案。随着时间的推移，不断检验和修改计划，加快初始决策速度，从而克服全面恢复方案的这一主要缺点。
事实证明，哪怕是最好的恢复计划，无论是全面灾难恢复计划还是特定灾难恢复计划都可能不完整。本文重点探讨可预知灾难的规划和准备。然而，如前面所述，有些意想不到的灾难会随时发生，恢复计划必须随机应变。
测试灾难恢复计划
不管是为了让审计人员满足、取悦管理人员、符合法规要求，还是真的为了企业拥有弹性，灾难恢复计划的编写如果没有经过完整、定期的测试，那简直就是浪费时间。恢复计划应当每年至少测试一次，并在计划本身或应用环境发生重大变化之后再测试一次。对于快速变化的弹性企业，其灾难恢复计划应当每三个月进行一次完整的测试。
测试的目地不是检验恢复计划是否通过。如果每次测试都完全成功，那么这种测试就毫无意义。最好的测试应会发现哪些部分不能正常运行，因为在测试中发现问题并加以改正的成本，要远远低于在真正的灾难恢复过程中发现问题并解决问题的成本。
定期测试是灾难恢复计划保持生命力的关键。尽管每一次测试都被视为一个独立的项目，有始有终，但测试本身是一个永无终结的过程。每一次测试都使企业有机会了解、提高自身的弹性。将讨论灾难恢复测试的准备、执行和追踪，以最大限度地了解和提高企业弹性。
四种类型的测试
灾难恢复测试的分类或演练方法有很多，下面重点讨论灾难恢复测试的四种基本类型：
- 呼叫测试。呼叫测试通常是企业最先执行的最简单的测试类型。呼叫测试的目的很简单：检验企业是否能够通过呼叫紧急通知列表上的所有电话号码，通知和召集它的恢复团队成员。有些呼叫测试包括通知和召集企业所有员工。如果某个或多个员工联系不上，为了保证呼叫测试不被中断，测试计划应用相应的规定。
- 排练或桌面式测试。排练很容易进行，持续时间短却很容易暴露问题。排练一开始便召集所有恢复团队成员，并向每人发放一份恢复计划副本。协调者简单描述灾难情况后，参与者开始讨论计划的每一步，并由恢复团队成员重点讨论各自的职责。讨论应当包括可能和不可能发生的情况，以及恢复事件发生的时间等。有时，协调者可以加大测试的难度，例如宣告某些成员不能到位或者洪水和断电灾难并发等。
- 模拟测试。一次模拟测试是一个完整的灾难恢复过程，它通过模拟事件或功能受损来检验企业的灾难恢复计划。例如，要测试电话应答系统，恢复人员、技术和程序都必须到位。但要注意，测试应该由测试人员进行入呼叫，而不是把真正的客户呼叫路由到恢复站点。大多数数据中心的恢复测试通过模拟方式进行，而不是冒险中断信息服务，将业务转移到恢复站点。
- 实际测试。一次实际测试也是一个完整的恢复过程，而且是测试真正的业务处理和功能。例如，真正的客户呼叫被路由到恢复站点，执行真正的任务，处理真正的订单。这种测试是企业恢复能力的最权威测试，也是更复杂、更冒险的测试，其复杂程度与企业进行一场真正的灾难恢复相差无几。
在现实测试中，这四种类型可以组合使用，恢复团队成员要到测试开始前的最后一分钟才知道测试的真正日期和时间。例如，在日常防火演习结束后，大部分员工可以返回工作岗位，但此时可能开始一次呼叫测试，要通知恢复团队模拟灾难已经宣告，一次实际的灾难恢复测试将马上开始。依据恢复计划，几个团队要转移到灾难恢复站点，执行企业恢复任务。测试包括恢复已保存的介质、恢复正常网络、重新路由电话线以及让系统上线等。一些实际的业务和功能被转移到恢复站点，而其他业务和功能的测试则采用模拟方式。
准备恢复测试
恢复测试应当由协调者领导。协调者负责编写测试场景，确保企业作好了执行、调整模拟恢复步骤的准备，通常还应当保证参与者专注于恢复测试。
灾难测试场景编写好之后，企业应当检查测试场景的合理性、可行性，清楚而有意义。在某个测试场景被批准采用，角色和职责也确定好了之后，应当举行测试前会议，以协调安排测试时间，设定期望并做好后勤安排。全天和几天的恢复测试通常需要在几个月时间内召开数十次甚至更多次会议，来进行各种准备和协调。
最好的恢复测试应当是有限制的灾难场景，特别是新组建的恢复团队。有限制的灾难场景能让参与者专注于易处理的可恢复问题，而不是用最糟糕的情况挫败他们，这只会使测试人员不知所措，错误百出。随着企业测试计划的日趋成熟，可能引入更复杂和更有挑战性的测试场景。例如，宣布重要恢复团队成员不能到位，必要备份磁带丢失，或者通往恢复站点的道路被封锁等。意外的复杂场景用来提醒恢复团队成员任何事情都有可能发生，有助于参与者保持积极参与解决问题的状态。
恢复测试计划需要考虑的事项
一方面，灾难恢复测试场景应当尽可能真实；另一方面，从实践的角度看，企业进行灾难恢复计划测试时，通常没有必要中断其正常功能。进行恢复测试规划时考虑企业运营的某些方面尤为重要，这包括：
- 保证企业正常运营。企业测试灾难恢复计划时应当避免引起灾难。恢复团队设计的测试应当不危害企业的正常运营。不管是恢复团队还是成员个人，都应当清楚保护企业正常运营需要采取的措施。引入的任何假设场景都应避免影响企业的正常运营，并能够被清楚识别，同时应让相关各方清楚地了解这种假设在真正的灾难中可能不会出现。
- 决定是否延迟测试。在恢复测试开始以前，如有必要应当有一个该测试是否可以被延迟的决定。如果企业过于繁忙，或者生产问题致使主要站点和系统不稳定，测试的额外压力会使情况恶化。这种情况下，延迟测试可能是更恰当的决定。
- 真实灾难。恢复测试过程出现真正灾难的频率非常高。当真实灾难发生时，有的测试参与者以为这是测试的组成部分，而有的参与者可能知道这是真实的灾难，但却不知道该采取测试措施还是真实灾难的恢复措施。解决这个问题的办法是，不同的测试应当采用不同的口令或代码，以区别于真实灾难。如果测试中发生真实灾难，协调者应当立即停止测试，传达灾难密码，启动真正的恢复程序。
- 真实灾难的谣传。在恢复测试过程中，不是恢复团队成员的员工也许以为某个真实的灾难已经发生。他们会因众人纷纷议论这场“灾难”而紧张惊慌，当灾难测试通知发送到毫无思想准备的各方时，这种惊慌尤其常见。因此所有恢复测试的传达应当首先说明“这只是一次测试”，以免产生混乱。
执行恢复测试
恢复测试一开始，应当举行一次所有参与人员都参与的介绍会议。介绍会议旨在传达测试的目的意义，并感谢团队的参与。尽管恢复测试是非常严肃的事情，但保持“轻松”的心情通常很有必要，它可以减轻压力，并有助于恢复人员区分测试和真正的灾难。测试不需要太正式，比如说，不要求统一着装。测试过程应当提供一些食物和饮料，特别是延时测试。在测试进度允许的范围内，企业一般会鼓励工作人员微调测试场景和恢复工作。
当恢复团队测试他们的部分恢复时，协调者应当做一份详细记录，内容包括测试部分、测试时间、测试持续时间、正常运行的部分，更重要的是要记下不能正常运行的部分。测试指挥部应当设在会议室或其他适当的地方。恢复团队应当到指挥部汇报工作结果，领取进展报告，请求援助。
恢复测试中遇到问题时应当做好记录，但测试通常应当继续进行，这样才能尽可能多地从测试中发现恢复计划的缺陷。例如，应用程序恢复团队丢失了一组必需的数据，这一事故应当记录下来，然后从实际应用中找回这组数据的副本，以便继续进行测试。然而，关键的是，在这一问题没有找到根源并排除时，不能简单地一笔带过。
恢复测试之后
灾难恢复测试结束后，组织者应感谢所有恢复团队成员的参与，并鼓励他们就恢复测试的成功或不足之处提出反馈意见。测试中遇到的问题应逐一记录，并及进安排彻底解决。测试结束后的短期内，协调者应公布测试报告，测试报告应记录遇到的所有问题，并推荐解决措施，具体包括问题解决的具体负责人或组织，以及问题解决的具体时间。
从灾难恢复或测试过程中吸取的经验和教训，要应用到恢复计划和下一次测试中。通过这种方式，企业的弹性才能日趋成熟，灾难恢复计划才能保持适应性。最重要的是，当与某一次恢复计划测试相关的所有措施都完成时，新一轮灾难恢复测试又应当开始。因此，恢复计划的测试越频繁，真正需要灾难恢复时它就越可靠。
图1 停机时间
图2 停机时间和数据丢失
