這種方式解決EMC儲存崩潰RAID離線問題，簡單又高效

故障描述：

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

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

解決過程

1 、硬碟檢測

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

2 、備份資料

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

3 、分析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 條帶的大小，以及每塊磁碟的順序。

4 、分析RAID 組掉線盤

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

5 、分析RAID 組中的 LUN 資訊

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

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

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

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

7 、 匯出所有資料

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

8 、驗證最新資料

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