设为首页 - 加入收藏 ASP站长网(Aspzz.Cn)- 科技、建站、经验、云计算、5G、大数据,站长网!
热搜: 创业者 手机 数据
当前位置: 首页 > 服务器 > 系统 > 正文

分析:如何让数据恢复不再亡羊补牢

发布时间:2017-01-02 08:35 所属栏目:52 来源:告白
导读:最近看到这样一则消息,某企业的一个重要数据中心突然瘫痪,最快同时也是最能把损失降到最低的解决方案就是用备份磁带进行恢复。幸运的是,该企业早已有很好地备份策略,但是结果并不令人十分满意,它的恢复工作整整持续了六天,才使得一切开始正常运转。 很

    【专稿】最近看到这样一则消息,某企业的一个重要数据中心突然瘫痪,最快同时也是最能把损失降到最低的解决方案就是用备份磁带进行恢复。幸运的是,该企业早已有很好地备份策略,但是结果并不令人十分满意,它的恢复工作整整持续了六天,才使得一切开始正常运转。

    很自然,这就会引发一系列的问题,首先,是什么导致了数据中心瘫痪?其次,恢复数据库为什么需要这么长的时间?最后,要改善这种数据恢复的时间,我们在未来还需要做些什么工作?

    这三个问题必须作为所有备份/恢复策略的一部分,一个成功的备份/恢复策略应该是能够做到恢复的能力和备份一样好。

    但需要指出的是,问题恐怕并不在于备份,而在于恢复,系统设计者应该以恢复数据为目标来架构,而不是以备份那些数据为目标。因此我们有必要对上述三个问题认真做答。

什么导致瘫痪?

    导致数据损坏的有多种可能方法,数据库软件的问题、文件系统的问题、设备却动的问题,或者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。因此,谁知道在这其中发生了什么问题呢,但是事实是数据损坏了。
上一页123下一页查看全文 内容导航
  • 第1页:什么导致瘫痪?
  • 第2页:该做些什么?
  • 第3页:从体系架构着手

(编辑:ASP站长网)

网友评论
推荐文章
    热点阅读