备份徒劳无功，社保基金中心丢失80万份文档

    DoSTOR存储分析 4月3日消息：某社保基金中心IT部门负责人王东近来一直苦恼不堪疲于奔命，他和他的同事连续加班工作了三个多月，终于把该社保基金中心丢失的80万份文档资料重新扫描进电脑中。这一切都是源于三个多月前的一次系统非正常宕机，由于整个备份过程中的一连串错误，该社保中心备份系统徒劳无功，无法起到应有的数据保护作用，而最关键的，造成备份系统无效的原因与备份软件和设施本身并没有关系，完全是由于人为因素。
  
     如果数据无法恢复，那么备份就是浪费时间和金钱。王东的案例并非偶然，根据业务分析公司 Enterprise Strategy Group(ESG)调研数据分析，全球大约有40%的数据恢复失败了，失败的原因并不在于备份软件或者磁带上，而是由于备份本身的复杂性所决定的。
  
     这次意外让该社保基金中心承受了灾难性的打击，最终的数据补救工作完成后，王东重新审视了一下这次灾难的发生过程，以及他们所采用的预防和备份系统：
  
    灾难的缘起

    王东所在的社保基金中心使用的是某国际品牌的集群服务器，运行Microsoft SQL 2005，连接到大约有3TB可用空间的存储阵列上，构成双机热备方案。该社保基金中心的数据库包括大约1.5TB的数据和图像文件，而且以每年300-500MB的数据量递增。
  
     社保基金中心的数据库主要保存的由纸质文件扫描得来的数字图像文件。因为图像文件对于磁盘空间的要求很高，所以数据库中图像文件的部分包括一个分割成文件组的分区表，以年为单位在文件组中作为一个单独的分区来保存相应的文件。
  
     当年的数据是一个读/写文件组，而一旦关闭，就标记成只读。然后整个数据库使用文件组（部分的）备份，接着备份事务日志。这些数据库备份文件再备份到磁带上，并妥善保管在各处。分区表是SQL 2005的新功能，可以让备份大型数据库的操作变得更加简便。因为在只读文件组里的数据不会改变，就不需要像读/写文件组里的信息那样经常性地做备份了。
  
     然而，这种灵活性增加了文件管理的复杂度。当新的读/写文件组加入数据库中时，这个文件组必须在同一时间作为另一个文件组进行备份，同时还要备份事务日志，这样才能完全恢复数据库并上线使用。
  
    问题的根源

    去年六月，一个磁盘阵列处理器报错了，王东给硬件的厂商打了一个电话，得到的建议是运行后台校验来修复RAID数据，这个建议非常合理，但是实际操作中却并没有奏效。
  
     要修复RAID数据，首先必须先解除LUN绑定，然后重新绑定两个损坏的LUNs。因此，王东必须把损坏的LUNs上存储的数据库文件组移动到另外一个准备好的LUN上。这个步骤是修复RAID数据必不可少的步骤，然而无法挽回的损失也正是发生在这个步骤。
  
     王东通过一台远程计算机上进行解除和重新绑定的操作，与此同时还有一个厂商工程师在帮助做相同的操作，在实际操作中，由于以前备份策略的设置的文档已经完全丢失，无论是王东还是厂商工程师都很难把LUN编号和服务器驱动器编号对应起来，而且有些文件被错误的挪到了要重新绑定的LUNs上。两个人最终勉强完成了重新绑定的工作，他们却发现有一个重新绑定的LUN里面错误的包含了数据文件和SQL备份文件。
  
     王东试图从磁带上恢复数据库的备份文件，有一个重要的文件，对于社保基金中心的数据库来说最主要的文件组（MDF），在正常的备份过程中被不经意地忽视了，这个文件就没有备份到磁带上。而如果没有这个文件，数据库就不能恢复并正常工作。这个时候王东才意识到，要想从备份磁带中把数据恢复完成，已经彻底不可能了。而他们平时所依赖的数据备份系统，在真正的问题来临的时候，并不能保护数据安全。
  
     王东在周末加班，使用以前手工备份的MDF文件把所有只读的历史文件都恢复了，也就是2000年至2005年的数据，但是2006年的所有数据却永远丢失了，因为即使有2006年当前的备份和事务日志的备份，相对应的MDF文件的备份也是需要的。为了尽快恢复业务，系统先调用了一个没有数据的2006年的文件组。2006年夏天，王东和他的同事们用了三个半月的时间把纸质文档重新进行了扫描。
  
    全新的备份架构
  
     这次意外的灾难给社保中心带来不小的损失，社保中心也因此开始重视数据保护方面的投入和评估，并重新审视了以往的备份架构。
  
     以前，王东他们是文件组和日志每天都做备份，完全备份（包括所有的文件组）则是一个季度做一次。
  
     现在，王东和他的同事对于如何从文件组备份成功恢复数据库有何要求已经相当清楚了，其中有一些是MS SQL 2005的新功能。现在，王东增加了额外的磁盘到阵列中，保证有7TB的可用空间，恢复数据库和执行常规检查的操作变得更加容易了，同时备份方案也变得更加完善和成熟。
  
     现在该社保基金中心安排了一组IT人员每天都会检查和验证备份日志，每月都会检查所有的数据库性能、备份程序和脚本。循环备份的文件也会得到检查，而且每一个预定的备份现在要三个人检查才算完成。该社保基金中心还执行端到端的备份，并每季度保存一次，保证整个数据库可以通过磁带上保存的每季度的完全备份得到恢复。
  
     该社保基金中心的事故带给我们的经验就是一定要保证备份/恢复的过程是有效的。没有实时记录一个重要的地址文件是该社保基金中心备份恢复失败的关键，这样的人为错误而造成的数据损失比我们想象的更为普遍，虽然一般并没有这么大的损失量。
  
     在意外删除之后，人们使用备份、快照或其他方式来恢复数据的过程，就叫做数据恢复。然后我们通常就会发现备份、快照或档案文件不起作用的情况，这就是向Ontrack这类恢复服务提供商寻求帮助的时候了，看看他们能不能帮你从服务器或者存储阵列中恢复你想要的数据。
  
     此外，整个故事还包括一个隐藏的信息：如果只依赖于RAID镜像，本地或远程复制/镜像，如果在一个地点有什么文件被删除了，另一个地方的也同样会被删除。所以如果你只依赖于复制和镜像，那么至少要使用常规快照作为补充，另外，尽快把这些快照备份到别的介质上去。
  
  

未经允许不得转载：DOIT » 备份徒劳无功，社保基金中心丢失80万份文档