你的公司可能已经制定灾难恢复计划，同时投资各项技术支持计划，但是仅仅这么做可能还不足以保证数据能够得到恢复。

　　过去几年，自然因素和人为因素引起的灾难越来越多，存储管理员都在仔细审查灾难恢复（DR）计划，精心测试DR计划。

　　这些都是好消息。但也存在坏消息，大多数计划并不能实现既定功能。大多数DR计划无法保护公司数据安全，下文列举了其中最主要的10个原因。

　　1没有制定DR计划

　　如果不是因为CNN，人们可能永远不会考虑灾难问题。存储管理员只关注每天发生了什么事，如系统性能、可靠度等。相比于DR，大多数企业更加注重备份工作，因为即使是中等规模的企业也会经常需要恢复数据。

　　很少有人经历过整个数据中心或者整个站点遭破坏的灾难。解决DR计划缺失问题，只有一个方法，就是要组织一人甚至多人制定一份DR计划。另外，这些人应该保证制定出成功的DR计划。

　　2没有制定业务连续性计划

　　许多人搞不清DR和业务连续性（BC）的区别。DR计划的目的在于，保证公司的计算机系统（以及系统中存储的数据）能在灾难后继续使用。但是对于公司而言，计算机系统只是其中的一部分内容。公司中还有DR计划中不曾包括的内容：员工、通讯系统、产品生产和输送系统、以及其它系统。

　　很有可能出现这种情况：数据中心运行良好，但公司运作却出现问题。计算机已经配备并运行，但是生产、输送产品的员工却因为物理资源匮乏，无法完成工作。或者，公司客户无法与你的销售人员或客服部门联系。简单地说，DR计划可能执行完好，但你的公司却无法继续运作。所以，你必须保证DR计划与BC计划配套。同样，应该由一人或多人共同承担责任，制定BC计划，与DR计划配套执行。

　　3公司需求和IT人员的工作重点不一致

　　存储部门往往会关注难以备份的系统。例如，备份和恢复专家都会花大量时间来确保数据库能够成功备份。专家之所以在数据库上花费最多的时间，是因为数据库是存储环境中最大也最麻烦的问题。接下来就是客户数据库，因为客户数据库进行一致性备份时不会丢失任何数据。

　　如果你问公司员工，哪个系统应该更受重视，他们肯定会说是客户数据库。在灾难发生后恢复数据库固然重要，但是公司员工可能会认为数据库应该最后恢复，因此两周或四周的恢复时间目标（RTO）都在可以接受的范围内。然而，他们希望客户数据库能在灾难发生后几分钟之内就恢复使用。

　　因为公司和IT人员之间存在这些不一致，客户数据库往往以24小时恢复点目标（RPO）和8小时RTO的方式进行备份，而不是像员工期待的那样几分钟就完成。DR的工作重点、DR设施和流程必须满足公司需求。需要有专人负责保证DR工作重点在公司DR计划中处于核心地位。

　　4需求和现实不一致

　　负责确定公司需求的员工应该明白，并非所有的需求都能在技术上实现。大部分公司员工都会要求RTO和RPO达到0秒，心情好的话可能会降为几分钟。他们希望灾难发生后能立刻访问数据，他们不能丢失任何数据。实际上，利用一些技术可以达到这个目标，可财务总监可能不会同意，因为在数据中心的每台计算机中采用这些技术，需要以成本作为代价。

　　因此，保证公司需求得到满足固然重要，但是保证需求具有实际意义同样重要。这个问题需要公司用户和IT人员协商，才能达成一致。他们之前可能会发生这样的对话：

　　用户：“我们需要1分钟的RTO和RPO。”

　　IT人员就像《王牌大贱谍》中的邪恶博士（Dr. Evil）似的，将小手指放在嘴边慢慢说道：“这个目标有可能实现。但是需要耗费100万美元。”

　　用户：“太贵了，那4小时的RTO和RPO呢？”

　　IT人员：“10,000美元。”

　　用户：“成交。”

　　如果你的公司一般不发生这样的对话，那么你的DR计划很有可能与公司需求存在出入。

　　5 DR计划只强调系统的RTO，不强调数据中心的RTO

　　大多数公司在协调RTO时，只是协调每个系统的RTO。举个常见的RTO例子：数据中心的任何系统必须在4小时内恢复。这种方法适用于操作恢复和系统断电的情况，但并不适用整个数据系统丢失的情况。通常认为，系统需要恢复到能够访问所有系统资源的水平。例如，大型数据库服务器需要恢复后，应该能访问磁带库中的20个磁带驱动器。但是，如果需要恢复20或100台服务器，又会发生什么现象？他们不可能同时访问磁带库里的20个磁带驱动器。

　　IT人员和需要DR计划的公司部门之间进行对话，可能最为困难。因为对话必然涉及传统备份和恢复模式的关键问题：实际中发生灾难时，存储部门往往不能满足RTO和RPO要求。除非公司离开数据也能生存几天，否则要想保证灾难后整个数据中心仍然可用，只有一个办法，即在灾难恢复之前就已经“恢复”数据。一直以来，这个目标可以通过复制功能实现。根据数据量的大小，也可以采用其它技术实现。但是实际上，大多数公司的RPO和RTO不能保证整个数据中心在灾难发生后立刻开始恢复。

　　6 DR计划没有包括一致性组

　　多个计算机系统通常为多个商业应用程序服务。这些系统需要即时恢复到同一个恢复点。但是通常情况下，这只是公司需求和IT人员工作能力之间不一致的又一处体现。除非一致性组（一致性组是指多个卷可以组成一个组，在多个存储单元之间统一管理，以创建一致性的数据复本。）已经创建，否则就不太可能有合适的技术，即时将一组系统恢复到同一时间点。没有快照、复制或者持续的数据保护系统等先进技术，就不可能创建一致性组。

　　7无法实现备份

　　有时候，DR问题的产生原因非常简单。一些公司具有DR计划，RTO和RPO也能实现，但是如果备份系统在灾难发生之前没有生效，DR计划也就没有意义了。许多备份系统已经部分或完全损坏。即使备份的成功率为95%，在灾难发生那晚还是有5%的数据没有得到备份。很少有公司知道哪些数据没有得到备份。系统中的这部分数据是随机分配的，情况可能没有那么糟糕。但是也有可能一直是同样的数据没有得到备份。许多公司对备份系统的连续性故障，都不予以追踪，这部分公司的数量令人吃惊。许多备份软件包也不追踪连续性故障，这是个无法谅解的问题。

　　造成很多备份系统故障的关键问题在于备份的管理方式。应该根据备份系统的成功率来评价管理人员的工作。这个想法听起来不错，却会给管理人员带来不必要的压力。结果，许多备份管理人员就会企图隐瞒管理不当引起的备份故障。他们认为，如果告诉别人备份出现故障，自己就会被解雇或扣奖金。他们相信，备份会在明天、下周或者下月得到完善，他们能在别人发现真实情况之前修复这些问题。

　　解决这两个问题的方法是选用保护数据、管理数据的商业软件。这些软件能提供很难访问的备份数据的信息，列出连续性故障的清单报告。有些软件也能帮你更好地理解故障原因，所以你能彻底解决问题，而不是不断地修复问题。最后，这些软件使得备份系统管理员无法隐瞒备份故障。这样，整个备份过程变得非常透明，公司主管可以打开Web浏览器，查看公司的备份过程。

　　8 DR计划没有经过测试

　　许多公司拥有DR计划，而且需求恰当、技术可行。然而，由于测试DR计划相当耗时、费钱，公司通常不会定期测试DR计划（每年至少两次）。

　　想想数据中心在一年中的变化有多大。只有定期测试DR计划，你才能发现其中的问题。例如，DR计划中可能没有包括新的应用程序；你的文档可能与三月前停用的软件版本匹配；或者服务器更新了，热备援却没有同步更新。找出这些问题只有一个方法，就是测试DR计划。

　　9寻常人员无法实现

　　公司认为，员工可以随时为灾难工作做好准备。但是，灾难多种多样，这种假设是否合理？例如，如果遇上水灾、风灾、雪灾等灾害，员工就无法在灾害发生后赶到办公室。如果桥塌了或者路断了，你的员工就可能无法抵达恢复站点。如果你的DR计划假设员工随时都能做好准备，就有点过了。你必须在DR计划中指定一些学识渊博的临时工。

　　更多地了解灾难恢复

　　在制定DR计划时，最好提供一份或多份DR服务的目录。简单地查看一下以下站点的文章内容，可以帮助你了解制定综合的DR计划需要做哪些工作。

　　10文档跟不上工作需求

　　如果你认为公司员工无法在灾难中及时作出反应，那就应该具有一流的文档。在实际中，大多数文档并非一流。一些文档没有正确维护，可能已过期，有些软件已经几个月或几年没有使用，引用的系统名称和任务名称早已不存在了。

　　自从上次更新文件之日起就在公司上班长期员工的文档很有可能已经过时。然而，临时工和新员工却需要最新的文档。

　　要避免发生这个问题，你需要更新存储环境中所有的文档。你还需要雇佣临时工测试DR计划，确保文档综合化、精确化、人人都可以理解。如果不是你公司的员工也能说出灾难发生时需要做哪些工作，那么你的文档就相当完美了。如果不能，你的文档还需进一步完善。