灾难恢复规划很容易过期，从而导致它不能发挥很好的作用。有些公司经常会处于不稳定状态——状况好的时候尽力保持快速的增长，状况差的时期则削减开支。如果您的灾难恢复规划仅仅是一个事后的考虑问题，那么将很难跟得上形势。

　　我的一位同事曾经给我讲过他个人多年以前的一段经历，当时他在一家大型备份存储技术供应公司工作。有一次，一位客户的邮件服务器出现故障(硬件故障，磁盘丢失)。这位客户建立了一台新的服务器并从磁带备份恢复系统。但是，系统始终无法恢复正常，提示电子邮件数据库(email database)损坏。然后，他们一遍又一遍地尝试恢复，结果仍然不行。随着时间的过去，他们开始着急慌乱了，恢复时间目标和业务也受到严重的影响。这样的情形把他们快要急疯了，于是他们去找备份恢复供应商提供技术支持。经过一系列的标准化故障处理步骤后，他们决定派一名专家去帮助该客户公司解决恢复问题。客户非常肯定地认为，备份已经被损坏了，或者是在恢复过程中恢复数据被损坏了。在完成故障检修之后，技术支持组很肯定磁带中的备份数据没问题。

　　于是，我的这位同事被派去解决这个问题。当时，故障已经出现两天了，公司上下简直都要疯掉了。他确定磁带数据没有问题，而且恢复数据与磁带上的数据一致。显然，结论是备份过程损坏了磁盘上的数据。不过，我这位同事进一步对问题进行了深入分析。简单地说，新服务器安装的操作系统和邮件服务器补丁比原来的服务器运行的操作系统和补丁版本要新。当新服务器尝试装载电子邮件数据库时，没有预期这样一个老的数据库结构，所以就报错。然后，我这位同事仅仅是卸掉两个补丁，邮件服务器就恢复成功了，没有任何障碍或报错。

　　这个故事说明，许多IT公司在制定灾难恢复规划时忽视了一个问题。那就是它们只是制定了规划，却没有对规划进行更新。显而易见，例子中遇到电子邮件灾难的这位客户如果严格遵从最佳做法，保持更新灾难恢复规划，使之与操作系统和补丁详细版本保持一致，就不会遇到这样的灾难了。

　　这个问题不仅仅是那些只有一台邮件服务器和直连磁盘的小型企业会遇到，大型企业也会有类似问题。我曾经与一家五百强的企业打过交道，从它们那里我得知了另外一个故事。这家公司完成了灾难恢复规划的所有过程，制定BIA(业务影响分析)、RTO(恢复时间目标)，并且一丝不苟地执行和测试。到2002年为止，它们所进行的一系列灾难恢复测试证明它们的解决方案是可行的，完全满足RTO。然后，业务也以惊人的速度持续增长。由于灾难恢复规划工作正常，测试工作逐渐就被怠慢下来，精力都转移到了一些更紧急的业务需求上。不过，与遇到邮件灾难的朋友们不一样，由于这家公司有良好的配置管理制度，所以它们一直严格地保持着配置文档记录。

　　在2006年，由于管理层的人事变动，公司来了一位新的CIO。查看了公司的灾难恢复规划之后，这位新CIO询问了最后一次系统测试是什么时候。相关人员支支唔唔的回答说：“上次全面测试是在2002年年底，但之后系统状况一直都很好。”结果，这位CIO还是要求进行了测试。尽管测试没问题，但远远不能满足RTO要求。从2002年到2006年，数据增长幅度太大，即使是现有的最快的磁带系统也无法满足公司的RTO要求。它们的解决方案是采用异步复制将数据拷贝到SAN存储和400英里之外的其它系统。这家公司执行了共置的(co-located)灾难恢复热站(hot DR site)并采用磁带作为存档介质。

　　这些故事都可以让我们学到一些关于灾难恢复的经验和教训。

　　将灾难恢复融入配置管理过程

　　很多公司都只是把灾难恢复看作是一个事后考虑，甚至是一个独立的预算项。如果您的公司属于这一类型，请您赶快改变这种想法。灾难恢复是一个完整的过程，而且绝不是一个事后考虑和反思。如果只是把它作为一个事后考虑，在面临压力时势必会忽视灾难恢复的一些最佳做法。如果您为灾难恢复单独列出一个预算线，请马上把它消掉。灾难恢复预算应该包含在核心项目成本中，而绝不是事后预算。

　　定期测试灾难恢复规划

　　配置管理变更事件应该包括灾难恢复测试，它是任何更新测试或系统配置变更测试的一部分。配置变更需要进行人员的培训，它也应该包含灾难恢复培训在内。而且，灾难恢复培训应该一年更新一次，并作为人力资源培训要求。

　　观察RTO趋势

　　系统的灾难恢复测试应该一年至少进行一次。根据每次测试情况追踪RTO趋势是检验当前的方法和技术是否能跟得上增长和变化形式的最佳方法。不仅数据增长会延长恢复时间或高可用性故障恢复时间，日益独立化或模块化的系统也会使业务系统的RTO延长。

　　来源：TT数据中心 译者：周姝嫣 责任编辑：scarlett

　　更多内容请关注机房360，www.jifang360.com，中国绿色数据中心