你做了什么自己没数吗？现在这个样子我们也没办法—阵列故障操作不当导致无法恢复数据

服务器 [服务器raid5磁盘阵列情况简介]
西藏某政府机构使用的一台MS SQL SERVER服务器，是由4块硬盘组成的raid5磁盘阵列，划分一个逻辑卷，单盘为73GSCSI硬盘，组建于一台IBM X225型号服务器上。操作系统为WINDOWS 2003。

[服务器磁盘阵列故障经过]
A、服务器在正常使用中raid忽然瘫痪，检查服务器发现已经有有3块硬盘为离线状态。
B、管理员采用了随便选择2块硬盘进行强制上线操作，但是操作系统无法启动。
C、使用WINPE光盘启动操作系统后，可以看到数据。
D、把备份好的数据库文件使用zip文件格式拷贝到移动硬盘上，在其他服务器机器上测试后发现备份文件无法正确解压但文件大小、名称都正确。
E、聘请第三方维保公司对服务器进行更换raid卡操作并且重建一组raid5阵列。
F、管理员在raid上重装系统后正常工作，同时试图修复zip文件中的数据库，经过一天的时间依然没有成功。

[服务器磁盘阵列数据恢复结论]
这个案例的结果完全不同于我以前分享的服务器数据恢复案例，因为数据遭到了严重破坏，无法按照客户的要求进行数据恢复。

[raid5 数据恢复失败的原因分析和raid5数据恢复建议]
A，服务器在使用RAID5阵列进行存储时一定要及时对raid进行维护，保证raid正常，一旦发现有一块硬盘离线后即使服务器可以运行但一定要及时备份数据，并且对出现故障的磁盘阵列进行rebuild操作。等到服务器瘫痪后才对raid磁盘阵列进行检查已经是事后补救了，数据恢复的难度也相应增大。

B，如果由于运维工作不及时或其他原因导致raid5阵列2块以上硬盘离线，切记不可随意选择硬盘上线，如果在选错盘的情况下启动系统将有可能导致raid状态改变，破坏磁盘阵列中的重要数据，导致数据恢复失败。具体应对方法可以参考张宇工程师的《RAID损坏后，我们该如何紧急应对？》这篇文章。

C，只要目录区正常或者部分正常，就可以使用PE看到目录，但这并不意味着数据区一定正常，其实在第二步中系统无法启动就是因为强势上线的操作是错误的，此时应该停止继续操作。而管理员在PE里读到目录，实际上已经对文件系统进行了载入，破坏了正常文件系统的元数据区(只是有可能破坏的不影响要恢复的数据)。

D，ZIP文件无法解压的原因是RAID结构错误。管理员通过强制上线操作上线了2块硬盘，此时共有3块硬盘在线，但是这3块硬盘中有一块是先离线的磁盘，这就导致了最新数据与先离线盘中的旧数据混合在一起。此时目录正确但数据区是混乱的，如果不对这3块硬盘进行全面的数据同步的话基本上市可以完整恢复数据的。

E，如果自己无法解决raid5阵列出现的故障需要聘请维保公司进行解决时要注意合同中确定有数据恢复的项目，可以让其代为进行数据恢复处理(但最好还是咨询几家专业的数据恢复公司，确定一下数据恢复方案)。如果维保公司没有数据恢复的服务范围，那么最好优先或者直接选择数据恢复公司。因为大多数情况维保公司没有数据恢复服务无法进行数据恢复只好再找数据恢复公司，这其中的转折不仅对数据的安全、流程规范等方面无法直接掌控，增加数据恢复难度、降低数据恢复成功率，而且导致费用增加(有时候大得可怕)。

F，导致本案例中数无法恢复的最致命操作就是重建RAID5。IBM X225使用SERVER RAID SUPPORT CD重建RAID时，默认会对所有数据进行清0。其它型号的服务器通常也会在重建raid时重新同步校验，打乱原有数据结构，不过完整同步的过程需要一定的时间，如果在同步没有完成的情况下中断同步还是可以对未同步的剩余数据进行数据恢复。

G，管理员进行了一天的同步，73G的RAID成员盘都已经同步完成了。数据已经完全毁了。
分享标题：你做了什么自己没数吗？现在这个样子我们也没办法—阵列故障操作不当导致无法恢复数据
标题路径：http://cdxtjz.cn/article/cphegi.html