实现和测试一个灾难恢复（Disaster Recovery DR）计划是一个很大的任务。比较典型的是，参加一个DR计划的开发、文档和测试工作的人员数目是和公司人数以及IT部门人数成比例的。不幸的是，总是比足够能完成任务所需的人员数量少。

　　作为一个网络专家，你需要为创造和测试DR计划做准备，或者帮助修改已有的计划。不从事网络的人在开发DR计划时总是不把网络当回事。他们假定网络已经在那儿了并且工作正常，甚至在可能面对偶然性灾难时也这么认为。

　　因为期望被设定的很高，因此你的工作颇具挑战性。为了减轻这个重担，你需要首先确认你参加了灾难恢复计划。我们给出了我们的网络专家指南来帮助你完成灾难恢复这样复杂的任务。

　　灾难恢复基础

　　在我们进入到正题以前，首先我们简单介绍一些灾难恢复的基础知识。

　　首先，总存在着对业务连续性（BC）和灾难恢复（DR）的混淆认识。业务连续性指的是在你的业务架构被修复好之前你尝试着继续工作。灾难恢复指的是你希望能够更快的恢复业务架构。这就意味着拥有关键IT架构的大机构组织不能有停机故障的问题，并且在灾难降临的时候马上能提供所有的业务服务。这些术语经常被合起来简称为“BC/DR”。当然，灾难恢复计划通常考虑的是所有的业务架构，而非仅仅是IT架构。

　　一个DR计划考虑到整个架构和个人事务的恢复，因此它经常使用计算机程序来完成。比如，我的公司使用Strohl的LDRPS软件来创建和维护我们的DR计划。

　　计划的一部分将要衡量架构的关键性和可接受的停机时间。为了完成此项任务，必须要做业务影响研究和风险分析。这些研究对架构和人员的关键性进行排序，帮助你决定什么将首先恢复，以及是否有一些不需要恢复的部分。

　　网络专家能为DR计划贡献什么?

　　总体来说，网络专家必须首先参与到DR计划过程中。DR计划的作者必须在遇到网络应用时将网络放在心上（还有非网络应用存在吗?）。网络专家必须提醒其他人网络在他们每日业务中的重要性。这让我想起了思科的广告战提醒了我们“网络的能量”。

　　当说到DR网络时，显然最快的使它工作的方法是一直把它开着。我总是对那些说“在你报告一个紧急情况时马上启动你的DR网络”的DR提供方案摇头。事实上，我满意的DR网络具有如下特征：

• 它始终开着，你可以在任何白天或黑夜时ping到它
  
• 在人们需要的任何时候你都能测试它
  
• 和生产网络具有相同的速度访问所有公司地点的连接

　　当然，你需要在公司的预算和理想的DR网络中做一个权衡。然而，在考虑付出多少的时候公司必须要考虑到业务影响和风险分析研究。如果所有的高级经理说他们需要在一个小时的灾难过程中访问邮件，那么就需要找到钱来支持网络和服务器资源来实现。