【存儲raid陣列故障的起因】
事情的起因是這樣的，這次經歷的數據恢復設備爲DL380系列存儲，存儲中存儲的是客戶公司內部文件和機密信息。存儲上共有6塊硬盤組成raid5陣列，在正常使用過程中存儲突然崩潰，強制重啓後無法找到存儲設備，再重啓還是這樣。客戶於是聯繫我們進行存儲層面的數據恢復。
·
【數據恢復故障分析】
經過和硬件部門同事的一同檢測和分析，大致可以推斷客戶這臺存儲的故障應該是raid模塊損壞，一般出現這種raid信息丟失或者raid模塊硬件損壞的原因多是由於多次的斷電造成的。說回到本次數據恢復過程中來，經過與客戶的溝通得知這臺存儲確實經歷過不正常的斷電關機，但當時並未出現異常因此並未引起重視，直到存儲崩潰後也沒有意識到這次故障與以前的意外斷電有聯繫。現在客戶存儲上的這6塊硬盤已經都沒有辦法通過正常途徑來進行提取了，想要提取數據只能進行數據恢復。
·
【數據恢復過程記錄】
1.既然存儲已經崩潰，我們首先要確定的就是硬盤有沒有物理損壞。Raid模塊損壞到目前爲止也只是推測，要想確定故障原因還是要按照數據恢復流程進行檢測。於是硬件部門的同時協助我們對客戶的6塊硬盤依次進行了物理檢測，所有硬盤正常，沒有物理損壞。
2.硬盤沒有物理損壞，硬件部門同事的工作也就結束了。剩下的工作就由我們進行數據恢復操作了，首先是在我們內部準備了一臺帶有冗餘功能的存儲作爲數據恢復平臺，把這6塊盤全部都鏡像到數據恢復平臺上。
3.接下來就是繁重的數據恢復工作了，首先分析了這個陣列的raid結構以及所有硬盤在陣列中的盤序、校驗方式和數據塊大小，分析過程持續了兩天終於宣告完成。接下來就利用這些分析得到的數據重新構建了一組raid5陣列。
4.數據恢復工作進行到這一步就可以進行邏輯校驗了，邏輯校驗沒問題後纔可以讓客戶進行數據驗證。雖然校驗成功後依然有客戶驗證數據恢復不通過的可能性，但是畢竟是少數，可以說是成敗在此一舉。
5.非常幸運，驗證通過。客戶對數據恢復結果再進行驗證也完全達到了存儲發生故障前的狀態，本次數據恢復工作圓滿結束。由於客戶的數據涉密級別高且對時間要求比較緊急，這次的存儲數據恢復工作從檢測到客戶驗證通過整整用了3天時間，在數據恢復的過程中也是一直保持在緊張的狀態，好在數據恢復成功可以好好的放鬆一下緊張的心情了。
【存儲數據安全小貼士】
1.存儲在工作時儘量保障電源穩定，關機時要採取正常的關機方式而不是直接斷電（這裏不要笑，確實有一部分人喜歡直接斷電而不是正常關機）。
2.服役年限比較久了的一些老設備要勤檢查，尤其是受過傷但依然在運行的設備更要分外上心，隨時注意工作狀態隨時維護。例如這次恢復的存儲，意外斷電後並沒有馬上出現故障而是平安運行了一段時間後才突然崩潰，一下讓人措手不及了。
3.最終要的一點就是對數據做好備份，抄襲一句話“數據千萬條，備份第一條”有了備份文件，就算是服務器崩潰了也可以做到有備無患，從容的進行修復而不會影響正常業務。