一、 故障描述

使用者的 EMC   FC   AX-4儲存 出現 崩潰 現象 , 整個儲存 空間 由 12 塊 1TB STAT 的硬碟組成的，其中 10塊硬碟組成一個RAID5的陣列，其餘兩塊做成熱 備盤使用。 由於 RAID5陣列中出現2塊硬碟損壞，而此時只有一塊熱備盤成功啟用，因此導致RAID5陣列癱瘓，上層LUN無法正常使用。

二、檢測磁碟

由於儲存是因為某些磁碟掉線，從而導致整個儲存不可用。因此接收到磁碟以後先對所有磁碟做物理檢測，檢測完後發現沒有物理故障。接著使用壞道檢測工具檢測磁碟壞道，發現也沒有壞道。

三、 備份資料

考慮到資料的安全性以及可還原性，在做資料恢復之前需要對所有源資料做備份，以防萬一其他原因導致資料無法再次恢復。使用 winhex 將所有磁碟都映象成檔案，由於源磁碟的扇區大小為 520 位元組，因此還需要使用特殊工具將所有備份的資料再做 520  to 512 位元組的轉換。

四、故障分析 及恢復過程

1、分析故障原因

由於前兩個步驟並沒有檢測到磁碟有物理故障或者是壞道，由此推斷可能是由於某些磁碟讀寫不穩定導致故障發生。因為 EMC 控制器檢查磁碟的策略很嚴格，一旦某些磁碟效能不穩定， EMC 控制器就認為是壞盤，就將認為是壞盤的磁碟踢出 R AID 組。而一旦 R AID 組中掉線的盤到達到 RAID 級別允許掉盤的極限，那麼這個 RAID 組將變的不可用，上層基於 RAID 組的 LUN 也將變的不可用。目前初步瞭解的情況為基於 RAID 組的 LUN 只有一個，分配給 SUN 小機使用，上層檔案系統為 ZFS 。

2、分析RAID組結構

EMC 儲存的 LUN 都是基於 RAID 組的，因此需要先分析底層 RAID 組的資訊，然後根據分析的資訊重構原始的 RAID 組。分析每一塊資料盤， 發現 8 號盤和 11 號盤完全沒有資料，從管理介面上可以看到 8 號盤和 11 號盤都屬於 H ot Spare ，但 8 號盤的 Hot Spare 替換了 5 號盤的壞盤。因此可以判斷雖然 8 號盤的 Hot Spare 雖然成功啟用，但由於 RAID 級別為 RAID5 ，此時 RAID 組中還缺失一塊硬碟，所以導致資料 沒有同步到 8 號硬碟中。繼續分析其他 10 塊硬碟，分析資料在硬碟中分佈的規律， RAID 條帶的大小，以及每塊磁碟的順序。

3、分析RAID組掉線盤

根據上述分析的 RAID 資訊，嘗試通過北亞自主開發的 RAID 虛擬程式將原始的 RAID 組虛擬出來 。但由於整個 RAID 組中一共掉線兩塊盤，因此需要分析這兩塊硬碟掉線的順序。仔細分析每一塊硬碟中的資料，發現有一塊硬碟在同一個條帶上的資料和其他硬碟明顯不一樣，因此初步判斷此硬碟可能是最先掉線的，通過北亞自主開發的 RAID 校驗程式對這個條帶做校驗，發現除掉剛才分析的那塊硬碟得出的資料是最好的，因此可以明確最先掉線的硬碟了。

4、分析RAID組中的LUN資訊

由於 LUN 是基於 RAID 組的，因此需要根據上述分析的資訊將 RAID 組重組出來 。然後分析 LUN 在 RAID 組中的分配資訊，以及 LUN 分配的資料塊 MAP 。由於底層只有一個 LUN ，因此只需要分析一份 LUN 資訊就 OK 了。然後根據這些資訊 使用北亞 raid 恢復 ( datahf.net ) 程式，解釋 LUN 的資料 MAP 並匯出 LUN 的所有資料。

五、 解釋 ZFS檔案系統並修復

1、 解釋 ZFS檔案系統

利用北亞資料恢復 ( datahf.net ) 自主開發的 Z FS 檔案系統解釋程式對生成的 LUN 做檔案系統解釋，發現程式在解釋某些檔案系統元檔案的時候報錯。迅速安排開發工程師對程式做 debug 除錯，分析程式報錯原因。接著安排檔案系統工程師分析 ZFS 檔案系統是否因為版本原因，導致程式不支援。經過長達 7 小時的分析與除錯，發現 ZFS 檔案系統因儲存突然癱瘓導致其中某些元檔案損壞，從而導致解釋 ZFS 檔案系統的程式無法正常解釋。

2、 修復 ZFS檔案系統

上述分析明確了 ZFS檔案系統因儲存癱瘓導致部分檔案系統元檔案損壞，因此需要對這些損壞的檔案系統元檔案做修復，才能正常解析ZFS檔案系統。分析損壞的元檔案發現，因當初ZFS檔案正在進行IO操作的同時儲存癱瘓，導致部分檔案系統元檔案沒有更新以及損壞。人工對這些損壞的元檔案進行手工修復，保證ZFS檔案系統能夠正常解析。

六、 匯出所有資料

利用程式對修復好的 ZFS 檔案系統做解析，解析所有檔案節點及目錄結構。部分檔案目錄截圖如下：

七、驗證最新資料

由於資料都是文字型別及 DCM 圖片，需要搭建太多的環境。由使用者方工程師指點某些資料進行驗證，驗證結果都沒有問題，資料均完整。部分檔案驗證如下 :

八、資料恢復結論

由於故障發生後儲存現場環境良好，沒用做相關危險的操作，對後期的資料恢復有很大的幫助。整個資料恢復過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間內完成資料恢復，經使用者驗收資料無誤，至此資料恢復工作結束。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31380569/viewspace-2645863/，如需轉載，請註明出處，否則將追究法律責任。