新疆某政府机构，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成员盘都已经同步完成了。数据完全毁掉了。