作者: 张宇,北亚 服务器数据恢复中心,转载请联系作者,如果实在不想联系作者,至少请保留版权,谢谢。
 
[数据恢复故障描述]
  新疆某政府机构,MS SQL SERVER服务器,硬件环境为:IBM X225,由4块73G SCSI硬盘组成RAID5,RAID中只划分了一个逻辑卷。操作系统为WINDOWS 2003。
  A、之前未发现故障,直至服务器瘫痪,再查服务器时,发现有3块硬盘离线。
  B、随便强制上线2块硬盘后,无法启动操作系统。
  C、使用WINPE光盘启动操作系统后,可以看到数据,将备份好的ZIP数据库文件拷贝到移动硬盘上。
  D、ZIP文件在另外的机器上测试,无法正确解压。
  E、请对应维保公司帮助恢复。
  F、其维保公司更换了一块新的RAID卡,直接重建成了一组RAID5。
  G、客户认为ZIP文件大小、名称都正确,应该可以修好,所以直接先在RAID上重装了系统并正常工作,同时试图修复ZIP文件,尝试了1天后,没有结果。这时,向数据恢复公司寻求帮助。
 
[数据恢复结论]
  与以往我叙述的数据恢复案例不同,我直接说数据恢复的最后结论:
因数据破坏严重,数据最终无法按客户要求恢复。
 
[案例分析]
  针对上面的故障描述作如下分析:
  故障描述A中,在使用RAID5做存储时,一定要及时维护RAID的正常状态,当RAID5一块硬盘掉线后,要及时备份数据到另外的存储体上,再及时REBUILD故障RAID。
  故障描述B中,RAID5存在2块以上硬盘离线时,一定要可以随意选择硬盘上线,如果选择错了,有些情况下,一启动系统,整个RAID的状态就会改变,有可能会破坏重要数据。参考《 RAID损坏后,我们该如何紧急应对?》
  故障描述C中,用PE可以看到目录是因为目录区正常或部分正常,并不见得数据区正常,其实系统无法启动就意味着强制上线的操作是错误的,不应该继续下去。在PE里读到目录,实际上已经对文件系统进行了载入,已经破坏了正常文件系统的元数据区(只是有可能破坏的不影响要恢复的数据)
  故障描述D中,ZIP文件无法解压即意味着RAID结构是错误的,实际上强制上线了2块盘(这时候有3块盘在线,仅有一块盘离线),但这3块盘里有一块是早就离线了的,所以合起来的数据是新鲜与陈旧的混合在一起的,虽然目录是正确的,但数据区是混乱的。这时候并未对这3块硬盘有全面的数据同步,基本还是可以完整恢复的。
  故障描述E中,如果和维保公司签订协议中确定有数据恢复的项目,可以让其代为处理(但最好还是咨询几家专业的数据恢复公司,确定一下处理方式)。如果维保公司并无数据恢复的服务范围,最好直接选择数据恢复公司。大多数情况下,如果客户直接找维保公司,维保公司再找数据恢复公司,可能会导致费用增加(有时候大得可怕),同时对数据安全、数据恢复流程的规范方面无法直接控制。
  故障描述F中,重建RAID5是此例中最致命的操作。IBM X225使用SERVER RAID SUPPORT CD重建RAID时,默认会清0所有数据。即使是其它服务器,重建RAID时一般也会重新同步校验,也会打乱原来的数据结构。但这个过程全部完成需要一段时间,如果没完成,可能剩余部分数据还有机会恢复。
  故障描述G中,经过了一天,73G的RAID成员盘都已经同步完成了。数据完全毁掉了。