【存储raid阵列故障的起因】

事情的起因是这样的，这次经历的数据恢复设备为DL380系列存储，存储中存储的是客户公司内部文件和机密信息。存储上共有6块硬盘组成raid5阵列，在正常使用过程中存储突然崩溃，强制重启后无法找到存储设备，再重启还是这样。客户于是联系我们进行存储层面的数据恢复。
·

【数据恢复故障分析】

经过和硬件部门同事的一同检测和分析，大致可以推断客户这台存储的故障应该是raid模块损坏，一般出现这种raid信息丢失或者raid模块硬件损坏的原因多是由于多次的断电造成的。说回到本次数据恢复过程中来，经过与客户的沟通得知这台存储确实经历过不正常的断电关机，但当时并未出现异常因此并未引起重视，直到存储崩溃后也没有意识到这次故障与以前的意外断电有联系。现在客户存储上的这6块硬盘已经都没有办法通过正常途径来进行提取了，想要提取数据只能进行数据恢复。
·

【数据恢复过程记录】

1.既然存储已经崩溃，我们首先要确定的就是硬盘有没有物理损坏。Raid模块损坏到目前为止也只是推测，要想确定故障原因还是要按照数据恢复流程进行检测。于是硬件部门的同时协助我们对客户的6块硬盘依次进行了物理检测，所有硬盘正常，没有物理损坏。
2.硬盘没有物理损坏，硬件部门同事的工作也就结束了。剩下的工作就由我们进行数据恢复操作了，首先是在我们内部准备了一台带有冗余功能的存储作为数据恢复平台，把这6块盘全部都镜像到数据恢复平台上。
3.接下来就是繁重的数据恢复工作了，首先分析了这个阵列的raid结构以及所有硬盘在阵列中的盘序、校验方式和数据块大小，分析过程持续了两天终于宣告完成。接下来就利用这些分析得到的数据重新构建了一组raid5阵列。
4.数据恢复工作进行到这一步就可以进行逻辑校验了，逻辑校验没问题后才可以让客户进行数据验证。虽然校验成功后依然有客户验证数据恢复不通过的可能性，但是毕竟是少数，可以说是成败在此一举。
5.非常幸运，验证通过。客户对数据恢复结果再进行验证也完全达到了存储发生故障前的状态，本次数据恢复工作圆满结束。由于客户的数据涉密级别高且对时间要求比较紧急，这次的存储数据恢复工作从检测到客户验证通过整整用了3天时间，在数据恢复的过程中也是一直保持在紧张的状态，好在数据恢复成功可以好好的放松一下紧张的心情了。

【存储数据安全小贴士】

1.存储在工作时尽量保障电源稳定，关机时要采取正常的关机方式而不是直接断电（这里不要笑，确实有一部分人喜欢直接断电而不是正常关机）。
2.服役年限比较久了的一些老设备要勤检查，尤其是受过伤但依然在运行的设备更要分外上心，随时注意工作状态随时维护。例如这次恢复的存储，意外断电后并没有马上出现故障而是平安运行了一段时间后才突然崩溃，一下让人措手不及了。
3.最终要的一点就是对数据做好备份，抄袭一句话“数据千万条，备份第一条”有了备份文件，就算是服务器崩溃了也可以做到有备无患，从容的进行修复而不会影响正常业务。

原文地址：https://blog.51cto.com/sun510/2408515