灾难恢复计划中的10大隐藏危险

随着最近几年人为的和自然的灾害频发，存储管理灾难恢复计划越来越多的需要测试和修正，这是一个好消息。但是坏消息是大部分容灾计划会失败。接下来10大原因是什么为什么大多数DR计划会失去保护企业数据的能力。

1. 没有容灾计划.

如果不是CNN，大多数人可能不会想到灾难。存储管理人员整天关注的是系统性能和可用性。备份更加的收到关注，因为一般的公司都能感受到有时需要恢复操作。
很少有人体验过灾难发生在他们的数据中心。唯一的解决没有灾难恢复计划的方法就是指定一个专人负责建立此计划。另外，这类人必需确保专注于确保容灾计划的存在和有效。


2. 没有业务连续性计划.

很多人会混淆灾，恢复和业务连续性。灾难恢复的目的是确保公司计算机系统和存储数据在灾难发生时可用。但是更多的关注是需要业务而不是计算机系统。人员，通信，生产，运输和很多其它类似系统都没有包含到容灾计划中。

我们可能有个功能完备的数据中心也有一个什么都不能做的公司。计算机系统可能是在运行，但是制造和运输产品的人没有工具完成他们的工作。或者公司的客户没有办法联系销售和客户服务部门。简短来说灾难恢复计划可能执行的很好但是你的业务却不能运行。所以必需明确灾难恢复计划和业务连续性计划捆绑在一起。另外，一个或更多的员工都应该有其唯一的职责来开发业务连续性和灾难恢复计划。
3. 在业务需求和IT优先之间不匹配
存储部门更关注哪些比较难备份的系统. 例如，备份和回复专家花费大量的时间确保数据仓库成功备份。专家证明花费在系统上的时间是值得的，因为它是一个企业中最庞大的也是风险最大的。接下来就是客户数据库和无中断的一致性的备份是最关键的。

如果公司业务的某人要求关注某些系统，他们肯定会说是客户的数据库。当然灾难后恢复数据仓库是重要的， 然而灾难后恢复数据仓库是重要的，业务用户可能会说这是最后一个需要回复的系统，2星期或者4个星期RTO都是可以接受的。然而他们期望客户数据库能够在灾难后能够在几分钟内恢复客户数据库。  


4. 需求和实际有所不匹配.

负责定义业务需求的人也得理解不是所有的事情都是技术性的。大多数商业人士可能要求RTO和RPO为零，如果心情好也许几分钟也可以。他们希望灾难后数据库可以立即使用,他们不能承受有数据丢失。这些在某些技术下是可以实现的，CFO可能不会同意在数据中心中使得这些技术应用每台计算机所需要的花费和成本。因此，满足业务需要是非常重要的，同样重要的是也得符合实际条件。这个问题需要商业用户和IT部门之间协商和研究。对话可能会像这样:

用户: "我们需要RTO和RPO为1分钟."

IT 人员: "可以，但需要花费100万美元"

用户: "T太贵了，4小时RTO和RPO怎样？"

IT人员: "我们只需要1万美元可以实现."

用户: "成交."


5. DR计划仅仅指出了系统的RTO而不是数据中心的RTO。

一个系统的RTO必须在4小时内恢复，然而这仅仅适用于操作回复或者系统级别的损失，当数据中心毁掉后却不是这样。通常假定系统回复需要所有的资源来访问它,例如一个大的数据库服务器需要恢复提供给磁带库的20个驱动器来使用，但是如果20或者100个服务器需要恢复时怎么办?
在灾难发生时，非常肯定的是存储部门无法满足RTO和PRO。除非公司能够在没有数据的情况下存活几天 ，唯一的方式是灾难后使得真个数据中心的数据可用。传统的可以通过复制来实现。根据数据量的大小，也可以通过其他技术来实现。实际上，大多数公司的RPO和RTO不允许在数据中心恢复后再恢复业务。


6. 灾难恢复计划没有包含一致性在组.

多个计算机系统经常服务多个应用业务。系统需要恢复到同一个时间点。一致性组(跨多个存储单元的卷的集合，通过创建数据的一致性拷贝进行管理)，不是在一个地方将所有系统同时恢复。没有高级的技术例如快照、复制、CDP是不可能实现一致性组的。

7. 备份没有工作.

优势灾难回复的问题根本是它太简单了。有些公司有RTO和RPO的灾难恢复计划，但是如果在灾难之前他们的备份系统没有工作，灾难恢复计划就不会工作。许多系统或许部分中断或者完全中断。即使一个成功的备份率达到95%也意味着5%的数据中心没有备份。很少由公司知道那5%的数据是什么。令人惊讶的是很多公司并没有跟踪这些备份系统中连续失败的原因。更糟糕的是有些备份软件没有跟踪这些核心数据。

导致备份系统失败的核心问题就是这些备份如何进行管理A。可以给成功备份的负责人打分，可能是个好主意，但给这些后来人无形增加了压力。结果是很多人会隐藏备份失败的次数。解决这些问题的办法是通过商业的备份软件，这些软件提供了关于备份的信息，提供了详细的报告列出连续的失败清单。还可以给你提供出这些问题的原因，可以修正。还可以除掉管理员隐藏备份失败的能力，对备份来说再也没有秘密，业主可以自己打开Web浏览器查看备份的状态。


8. 灾难恢复计划没有测试.

许多公司有DR计划，可能会有技术可以实现的实际需求。然而测试DR计划是非常耗费时间和成本的，经常不会做充分的测试(至少一年2次)。考虑一下数据中心一年有多大的改变，只有测试DR计划时才能发现潜在的问题。一个新的业务应用可能没有包含到计划中；文档可能只符合3个月前已经停止使用的软件版本；或者升级服务器的时候但是在线站点并没有很好的升级。要发现这些问题的方法就是测试DR计划。

9. 平时人的人们不可用.

公司假设恢复操作时自己的人员都可用。但是考虑一下不同类型的灾难考虑一下这个假设是否有道理。也许灾难是水、雪、风。任何这种灾难都会使得员工无法到达办公室。如果桥梁或者公司无法通行，关键人员都无法到达恢复站点。如果假设了人员时可用的，那么假设是太多了。应该在灾难恢复计划中，确保有住宿来保持有知识的临时人员。
                               
                       
10.文档没有跟进工作.

如果假设灾难中人员无法可用，但需要确保文档第一时间更新。很少维护的文档会过期，引用的软件版本，系统名称和命令可能都不再用了。解决问题的方式就是需要更新所有的文档，也会用到临时人员来测试DR确保文档能够被理解、正确的。如果不在公司的人员能够描绘出灾难发生时该做什么，那么说明文档是非常好的。