可以证明地是，测试IT灾难恢复计划的两个最重要的因素是保持计划的更新和测试该计划在关键时刻是否是有效的。

　　在理想情况下，每年你都要带领灾难恢复团队只用备份磁带和新硬件在离线环境中无差错地重建和恢复原有产品系统。听起来好像不错吧?但不幸地是，绝大多数公司没有能力每年都对其灾难恢复计划进行全面测试。即使有这个能力的公司也需要在此基础上投入更多。

　　因此我的问题是：你如何避免在凌晨2：00打电话给你老板，请他/她原谅你，因为你忘记了对分布式文件系统(DFS)共享中放置重要文件的用户验证身份。

　　测试灾难恢复计划有4个主要部分。其中两个步骤是识别出源文件并口头预排计划。另外两个步骤分别是利用现有方案和从错误中学习，将在在第二部分中详细描述。

　　识别源文件

　　源文件识别是灾难恢复计划的基本概念，但许多人都没有正确认识它。你知道灾难恢复后如何获取所有软件的拷贝，如何重建个人应用程序吗?过于自信的一方也许会说：“没关系，已经备份好了。”但我对此的第一反应却是：“你敢保证吗?我能获得拷贝吗?马上可以吗?”

　　也许你以为大部分都备份好了，但如果你仔细审查备份，就会发现还是有些东西丢失了，如数据库架构，存储程序，防火墙规则集和DFS共享。对于DFS共享来说，用户放置源文件的目录是否是正确的呢?你还忽视了最基本的一点---你有微软Windows Server 2003的拷贝吗?

　　你永远无法预知什么时候你的备份会失效，以至于你需要一个拷贝从头开始。

　　别忘了询问你的团队成员是否他们使用了一些工具进行离线备份，如针对Windows Server 2008和Exchange 2007的自定义LDAP搜索脚本，VB脚本以及PowerShell脚本。

　　口头预排

　　给团队成员买比萨饼，只需花费50美元，但如果能借此及时发现存在的问题，带来的效益却是无价的。

　　你会惊讶于花半小时与你的团队成员一起吃午餐能给你带来什么。开放的讨论对于获取你公司应对灾难能力的情况是相当有好处的。要使这一活动获得成功，你必须事先花一些时间对议程作个计划。

　　评价灾难恢复准备的议程如下：

　　◆概述(会议目标)

　　◆Windows Server组

　　   ●组长作DRP陈述

　　   ●假设分析

　　   ●基于分析结果要采取的措施

　　◆活动目录组

　　   ●组长作DRP陈述

　　   ●假设分析

　　   ●基于分析结果要采取的措施

　　◆微软SQL Server组

　　   ●组长作DRP陈述

　　   ●假设分析

　　   ●基于分析结果要采取的措施

　　◆Exchange/Messaging组

　　   ●组长作DRP陈述

　　   ●假设分析

　　   ●基于分析结果要采取的措施

　　◆措施项(总结)

　　假设分析("what if analysis")是指组内每个人都向其它小组成员问一个假设性的问题，看他们如何应对各种可能出现的故障。

　　最后一步是确定下次会议的时间，确保每个组都将提出的措施付诸实践。各组组长分别负责相应的措施。这种活动可以每季度举行一次，以保证每个人对灾难恢复都引起足够的重视