很自然，这就会引发一系列的问题，首先，是什么导致了数据中心瘫痪？其次，恢复数据库为什么需要这么长的时间？最后，要改善这种数据恢复的时间，我们在未来还需要做些什么工作？
这三个问题必须作为所有备份/恢复策略的一部分，一个成功的备份/恢复策略应该是能够做到恢复的能力和备份一样好。
但需要指出的是，问题恐怕并不在于备份，而在于恢复，系统设计者应该以恢复数据为目标来架构，而不是以备份那些数据为目标。因此我们有必要对上述三个问题认真做答。
什么导致瘫痪?
导致数据损坏的有多种可能方法，数据库软件的问题、文件系统的问题、设备却动的问题，或者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）来说是没有任何帮助的，但它确实改进了备份的时间。
该做些什么？
要理解恢复的重要性，首先需要了解为什么需要恢复。从我们所看到的一切，恢复在桌面环境是非常重要的，因为经常有一些粗心的使用者会误删除一些文件，这差不多是最普遍的恢复问题。这种情况下，虽然你不是恢复大量的数据，但是你差不多经常会做这样的“小型”恢复。另一方面，如果一个关键应用数据库不见了，你必须恢复整个事情，这就变成了一个关键事件，你的业务将取决于你恢复那个数据库的速度有多快。
那么，该企业的应用有什么不同呢？
该企业使用了一个以不变应万变的备份/恢复策略，从专家的角度看，这对桌面环境来说不太好，对关键业务应用环境甚至更糟糕，因为它是试图最优化备份的问题，而不是恢复的问题。
当员工说明问题的时候是根据备份操作能够多快，而不是恢复数据需要多长时间的时候，经常就会出现这样的问题。而当他们说明问题且感觉到恢复的痛苦时，通常是指桌面环境，而不是关键业务数据。很不幸的是，管理部门往往不深入考虑就基于员工反映的那种类型的恢复做出了预算。
那么这个企业遇到数据库瘫痪后能做些什么工作呢？简要地回答，并不多，因为本质问题是在体系架构上，不是什么后续的程序或手续能够解决的。尽管该企业并不是必须组合客户磁带流，但它并没有时间来等待在时间窗口中完成所有的备份。遇到这样的情况有多种选择，但最有效的还是从架构上去做改进。
从体系架构着手
需要指出的是，并不是备份通常不如恢复重要，而最重要的是，一个单纯的备份架构是不可能解决备份和恢复的多样化问题的。
你必须考虑很多的事情，诸如：不同级别的存储性能，以确保磁带能够同步运转；对不同客户端潜在地有不同的网络拓扑，以便单一的数据流能够全速传到磁带；D2D备份/恢复；D2D2T备份/恢复；潜在的基于主机的备份/恢复等。这些只是一部分需要考虑的问题，针对不同类型的备份/恢复需求，你可能还需要不同的体系架构。
其实，和存储打交道就是非常艰难的一件事情，因为存储不会随着CPU性能而扩展，所以在数据生成过程中产生麻烦也是很普遍的。这种趋势不会改变，所以也不必在出现问题的时候责怪谁，出现问题是早晚的事情，关键是要搞清楚什么是可以通过软件和硬件来做的，而什么又是做不到的。
如果你想让事情得到彻底解决，那就投入资金，来重新创建一个不同的基础架构来满足需求吧。也许你经常听到领导希望对桌面的备份/恢复和对关键业务应用的备份/恢复能完全一样，那你就直接告诉你的领导，不投入大量的工作和资金，这是不可能实现的，因为它们本身就不是一回事。
