|
恢复时间为什么那么久？
本文开头提到的是一个大型企业应用环境，备份操作是通过一个备份客户端和服务器来实现，有磁带驱动器连接到备份服务器。由于客户端大多时候是通过千兆以太网来连接的，所能达到的绝对最高传输速率也只有大约60MB/sec。
你也许能够记得一些关于LTO-3的数字指标，磁带驱动器对于未压缩的数据传输速率能够达到80MB/sec，而对于压缩的数据其传输速率更近乎是可以翻倍。在本文开头谈到的这个企业计算环境中，数据一般都做了压缩，磁带被写入的速度平均为140MB/sec，这比所谓无异议的GigE要快得多了。为了优化备份的性能，该企业计算环境中还采用组合多个客户端数据流、写入同一磁带的方法。
尽管这确实改善了备份的性能，但也对数据恢复性能造成了反面影响。现在不得不将若干磁带一起安装来恢复文件，因为它们是多个机器组合而来的。事实上，对于该企业来说，所要恢复的数据只有6TB，但却必须安装140个磁带；而实际上6TB的数据只要在15个LTO-3磁带上就差不多就能装完。
结果，仅安装那些数量巨大的磁带就用了三个多小时的时间。因此，应用那种备份技术导致这些额外的时间消耗，对于满足恢复的SLA（service-level agreements）来说是没有任何帮助的，但它确实改进了备份的时间。
该做些什么？
要理解恢复的重要性，首先需要了解为什么需要恢复。从我们所看到的一切，恢复在桌面环境是非常重要的，因为经常有一些粗心的使用者会误删除一些文件，这差不多是最普遍的恢复问题。这种情况下，虽然你不是恢复大量的数据，但是你差不多经常会做这样的“小型”恢复。另一方面，如果一个关键应用数据库不见了，你必须恢复整个事情，这就变成了一个关键事件，你的业务将取决于你恢复那个数据库的速度有多快。
那么，该企业的应用有什么不同呢？
该企业使用了一个以不变应万变的备份/恢复策略，从专家的角度看，这对桌面环境来说不太好，对关键业务应用环境甚至更糟糕，因为它是试图最优化备份的问题，而不是恢复的问题。
当员工说明问题的时候是根据备份操作能够多快，而不是恢复数据需要多长时间的时候，经常就会出现这样的问题。而当他们说明问题且感觉到恢复的痛苦时，通常是指桌面环境，而不是关键业务数据。很不幸的是，管理部门往往不深入考虑就基于员工反映的那种类型的恢复做出了预算。
那么这个企业遇到数据库瘫痪后能做些什么工作呢？简要地回答，并不多，因为本质问题是在体系架构上，不是什么后续的程序或手续能够解决的。尽管该企业并不是必须组合客户磁带流，但它并没有时间来等待在时间窗口中完成所有的备份。遇到这样的情况有多种选择，但最有效的还是从架构上去做改进。
上一页123下一页查看全文
内容导航
（编辑：ASP站长网）
|
居龙：中国大陆首次成