推荐给好友 上一篇 | 下一篇

备份徒劳无功 社保数据损失80万

    某社保基金中心IT部门负责人王东近来一直苦恼不堪疲于奔命,他和他的同事连续加班工作了三个多月,终于把该社保基金中心丢失的80万份文档资料重新扫描进电脑中。这一切都是源于三个多月前的一次系统非正常宕机,由于整个备份过程中的一连串错误,该社保中心备份系统徒劳无功,无法起到应有的数据保护作用,而最关键的,造成备份系统无效的原因与备份软件和设施本身并没有关系,完全是由于人为因素。

    如果数据无法恢复,那么备份就是浪费时间和金钱。王东的案例并非偶然,根据业务分析公司 Enterprise Strategy Group(ESG)调研数据分析,全球大约有40%的数据恢复失败了,失败的原因并不在于备份软件或者磁带上,而是由于备份本身的复杂性所决定的。

    这次意外让该社保基金中心承受了灾难性的打击,最终的数据补救工作完成后,王东重新审视了一下这次灾难的发生过程,以及他们所采用的预防和备份系统:

    灾难的缘起
    王东所在的社保基金中心使用的是某国际品牌的集群服务器,运行Microsoft SQL 2005,连接到大约有3TB可用空间的存储阵列上,构成双机热备方案。该社保基金中心的数据库包括大约1.5TB的数据和图像文件,而且以每年300-500MB的数据量递增。

    社保基金中心的数据库主要保存的由纸质文件扫描得来的数字图像文件。因为图像文件对于磁盘空间的要求很高,所以数据库中图像文件的部分包括一个分割成文件组的分区表,以年为单位在文件组中作为一个单独的分区来保存相应的文件。

    当年的数据是一个读/写文件组,而一旦关闭,就标记成只读。然后整个数据库使用文件组(部分的)备份,接着备份事务日志。这些数据库备份文件再备份到磁带上,并妥善保管在各处。分区表是SQL 2005的新功能,可以让备份大型数据库的操作变得更加简便。因为在只读文件组里的数据不会改变,就不需要像读/写文件组里的信息那样经常性地做备份了。

    然而,这种灵活性增加了文件管理的复杂度。当新的读/写文件组加入数据库中时,这个文件组必须在同一时间作为另一个文件组进行备份,同时还要备份事务日志,这样才能完全恢复数据库并上线使用。



TAG: 备份
31/3123>
 

评分:0

我来说两句

seccode