很自然，这就会引发一系列的问题，首先，是什么导致了数据中心瘫痪？其次，恢复数据库为什么需要这么长的时间？最后，要改善这种数据恢复的时间，我们在未来还需要做些什么工作？
这三个问题必须作为所有备份/恢复策略的一部分，一个成功的备份/恢复策略应该是能够做到恢复的能力和备份一样好。
但需要指出的是，问题恐怕并不在于备份，而在于恢复，系统设计者应该以恢复数据为目标来架构，而不是以备份那些数据为目标。因此我们有必要对上述三个问题认真做答。
什么导致瘫痪?
导致数据损坏的有多种可能方法，数据库软件的问题、文件系统的问题、设备却动的问题，或者RAID或磁盘固件等问题均有可能损坏数据。
在很多场合，相信你也曾经遇见过光纤通道交换机和光纤通道电缆损坏文件的情况。你可能会想，这应该是一些高级协议，如SCSI等的控制器损坏了，或者光纤通道CRC可能需要转发retransmit，但是很遗憾两种情况都没有发生如你想像的那种情况。
这就更让值得我们继续探究下去，是不是能够围绕UDBER（undetectable bit error rate）更深入地去了解这个问题呢？所谓无法检测到的错误基本上都是出现在当同时遇到两个问题的时候，以致错误编码机制并没有拾取到这个错误。
在因特网上有公开的关于磁带的UDBER数字，资料显示，LTO的UDBER值是10E-27，而Sun T10000的UDBER值为10E-33。这两个数字都很小，也就是说在这两种设备上出现UDBER的几率是很低的。另一方面，光纤通道的位错误率是10E-12，SATA是10E-14，光纤通道磁盘驱动器是10E-15。但是，关于这些设备的UDBER究竟是多少，我们却不得而知，因为没有任何关于它们的公开资料。
通常当发生数据损坏的时候，大家很容易把矛头指向软件，也许是因为从软件开始着手找错误更容易一些。但是随着各种通道的速度变得越来越快，磁盘驱动器的错误编码却很长一段时间都没有改变。需要提醒大家记住一点，你必须加入从CPU到存储设备的完整数据路径来计算UDBER。因此，谁知道在这其中发生了什么问题呢，但是事实是数据损坏了。
恢复时间为什么那么久？
本文开头提到的是一个大型企业应用环境，备份操作是通过一个备份客户端和服务器来实现，有磁带驱动器连接到备份服务器。由于客户端大多时候是通过千兆以太网来连接的，所能达到的绝对最高传输速率也只有大约60MB/sec。
你也许能够记得一些关于LTO-3的数字指标，磁带驱动器对于未压缩的数据传输速率能够达到80MB/sec，而对于压缩的数据其传输速率更近乎是可以翻倍。在本文开头谈到的这个企业计算环境中，数据一般都做了压缩，磁带被写入的速度平均为140MB/sec，这比所谓无异议的GigE要快得多了。为了优化备份的性能，该企业计算环境中还采用组合多个客户端数据流、写入同一磁带的方法。
尽管这确实改善了备份的性能，但也对数据恢复性能造成了反面影响。现在不得不将若干磁带一起安装来恢复文件，因为它们是多个机器组合而来的。事实上，对于该企业来说，所要恢复的数据只有6TB，但却必须安装140个磁带；而实际上6TB的数据只要在15个LTO-3磁带上就差不多就能装完。
结果，仅安装那些数量巨大的磁带就用了三个多小时的时间。因此，应用那种备份技术导致这些额外的时间消耗，对于满足恢复的SLA（service-level agreements）来说是没有任何帮助的，但它确实改进了备份的时间。
该做些什么？
要理解恢复的重要性，首先需要了解为什么需要恢复。从我们所看到的一切，恢复在桌面环境是非常重要的，因为经常有一些粗心的使用者会误删除一些文件，这差不多是最普遍的恢复问题。这种情况下，虽然你不是恢复大量的数据，但是你差不多经常会做这样的“小型”恢复。另一方面，如果一个关键应用数据库不见了，你必须恢复整个事情，这就变成了一个关键事件，你的业务将取决于你恢复那个数据库的速度有多快。
那么，该企业的应用有什么不同呢？
该企业使用了一个以不变应万变的备份/恢复策略，从专家的角度看，这对桌面环境来说不太好，对关键业务应用环境甚至更糟糕，因为它是试图最优化备份的问题，而不是恢复的问题。
当员工说明问题的时候是根据备份操作能够多快，而不是恢复数据需要多长时间的时候，经常就会出现这样的问题。而当他们说明问题且感觉到恢复的痛苦时，通常是指桌面环境，而不是关键业务数据。很不幸的是，管理部门往往不深入考虑就基于员工反映的那种类型的恢复做出了预算。
那么这个企业遇到数据库瘫痪后能做些什么工作呢？简要地回答，并不多，因为本质问题是在体系架构上，不是什么后续的程序或手续能够解决的。尽管该企业并不是必须组合客户磁带流，但它并没有时间来等待在时间窗口中完成所有的备份。遇到这样的情况有多种选择，但最有效的还是从架构上去做改进。
存储咨询公司Toigo Partners International LLC的资深分析师Jon William Toigo表示，灾难恢复对于IT组织来说很少是一个首要解决的问题，它通常只是一种保险策略，并没有投资回报，这也就是为什么这样的项目很难获得资金支持的主要原因。
全美大型医疗机构之一Baptist Memorial卫生保健公司的信息服务系统工程师Hal Weiss就表示，由于预算限制以及所在行业的独特问题，他在说服上层管理者同意对灾难恢复升级进行资金投入方面就有苦难，“我们依赖于公共医疗补助制以及医疗保险，主要看对于该计划他们计划偿还我们多少钱，”
Weiss在解释为什么资金是一个主要问题时说，“我并不能使用组织购买的应用软件，因为他们是由临床医生来指令的，有的时候一个应用软件并不能借给数据灾难恢复策略，一台机器在一个时间段只能运行一种特定的任务。”
Weiss还提到，Baptist Memorial有两套来自不同厂商的SAN，必须有两套灾难恢复计划，因为这些不同厂商的网络交换机并不能相互通信。
Todd说Pacific Capital通过对数据进行分级削减了灾难恢复的成本，因为这样就不必对所有的数据进行离线复制了，只有那些关键业务系统的信息被复制即可。而确定哪些数据是关键的这个工作只需要银行的法律部门来确定就可以了，这样也避免了和什么都想保护的业务部门之间发生政治斗争。
另外一个令Todd和Weiss都担心的问题是，需要一个删除政策。Weiss说他们医院不能删除数据，因为必须保存所有信息以便遵从联邦的、州的以及本地的法规。“在银行这也是一个问题，”Todd 说，“我们要决定哪些数据可以删除必须经由法律部门来决定。在决定期间，我们必须保存一切。”
为SMB起动网格
纽约正在发动资金来发展供中小型商业企业使用的备份存储的数据网格，州政府认为这种规模的企业在对付灾难方面准备不够充分。
事实也证明了这一点，某调查机构针对237个小型商业企业的调查结果显示，大多数企业对于灾难并没有做好准备。其中73%的被调查企业并没有任何关于详细灾难策略的书面计划；27%的被调查企业有计划，但是其中五分之一的企业并没有每年对该计划进行审核。
通过这样的建设，能够确保在遭遇任何无法预料到的破坏性事件以后，企业业务能够快速恢复数据。纽约州办公室的发言人表示，经历了9.11事件以及一些重大自然灾害和人为灾难所带来的惨痛教训，必须探索网络计算以及协作计算的潜能，来帮助企业真正实现灾难恢复。
该网格项目由纽约Poughkeepsie的Marist College提议发起，该大学最近已经获得了15万美元的一笔初始政府资金，在一年内开发完成原型。根据Marist大学计算机科学及数学学院院长Roger Norton介绍，完整的网格大概需要三年左右的时间来完成，整个开发工作以及刀片服务器、SAN网络硬件等的花费将超过50万美元。
Norton表示，他们的意图是使企业能够使用Web Service在网格中做日常数据备份，这种方式不仅安全，而且能够满足法规遵从的需求。该网格将在间隔50英里的三个不同地点来存储数据复本。这遵守数据网格的基本概念，也就是创建一个虚拟信息池，而不是约束在一个指定的地点。
目前Marist运行的IT项目已经与IBM达成长期合作，在接下来的一年中，Marist希望能有几个企业在原型基础上使用网格。网格的长期存储需求是非常重要的，这取决于有多少公司签约使用它，据Norton介绍，在试运行阶段该网格将提供3TB的存储空间。
本文由上海安全信息（安信）数据恢复中心 收集