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

故障描述：
因爲RAID5陣列中出現2塊硬盤損壞，而此時只有一塊熱備盤成功激活，所以致使RAID5陣列癱瘓，上層LUN沒法正常使用，整個存儲空間由12塊1TB SATA的硬盤組成的，其中10塊硬盤組成一個RAID5的陣列，其他兩塊作成熱備盤使用。
因爲前兩個步驟並無檢測到磁盤有物理故障或者是壞道，由此推斷多是因爲某些磁盤讀寫不穩定致使故障發生。由於EMC控制器檢查磁盤的策略很嚴格，一旦某些磁盤性能不穩定，EMC控制器就認爲是壞盤，就將認爲是壞盤的磁盤踢出RAID組。而一旦RAID組中掉線的盤到達到RAID級別容許掉盤的極限，那麼這個RAID組將變的不可用，上層基於RAID組的LUN也將變的不可用。目前初步瞭解的狀況爲基於RAID組的LUN只有一個，分配給SUN小機使用，上層文件系統爲ZFS。
解決過程
一、硬盤檢測
因爲存儲是由於某些磁盤掉線，從而致使整個存儲不可用。所以接收到磁盤之後先對全部磁盤作物理檢測，檢測完後發現沒有物理故障。接着使用壞道檢測工具檢測磁盤壞道，發現也沒有壞道。

二、備份數據
考慮到數據的安全性以及可還原性，在作數據恢復以前須要對全部源數據作備份，以防萬一其餘緣由致使數據沒法再次恢復。使用winhex將全部磁盤都鏡像成文件，因爲源磁盤的扇區大小爲520字節，所以還須要使用特殊工具將全部備份的數據再作520 to 512字節的轉換。
三、分析RAID組結構
EMC存儲的LUN都是基於RAID組的，所以須要先分析底層RAID組的信息，而後根據分析的信息重構原始的RAID組。分析每一塊數據盤，發現8號盤和11號盤徹底沒有數據，從管理界面上能夠看到8號盤和11號盤都屬於Hot Spare，但8號盤的Hot Spare替換了5號盤的壞盤。所以能夠判斷雖然8號盤的Hot Spare雖然成功激活，但因爲RAID級別爲RAID5，此時RAID組中還缺失一塊硬盤，因此致使數據沒有同步到8號硬盤中。繼續分析其餘10塊硬盤，分析數據在硬盤中分佈的規律，RAID條帶的大小，以及每塊磁盤的順序。
四、分析RAID組掉線盤
根據上述分析的RAID信息，嘗試經過北亞自主開發的RAID虛擬程序將原始的RAID組虛擬出來。但因爲整個RAID組中一共掉線兩塊盤，所以須要分析這兩塊硬盤掉線的順序。仔細分析每一塊硬盤中的數據，發現有一塊硬盤在同一個條帶上的數據和其餘硬盤明顯不同，所以初步判斷此硬盤多是最早掉線的，經過北亞自主開發的RAID校驗程序對這個條帶作校驗，發現除掉剛纔分析的那塊硬盤得出的數據是最好的，所以能夠明確最早掉線的硬盤了。
五、分析RAID組中的LUN信息
因爲LUN是基於RAID組的，所以須要根據上述分析的信息將RAID組重組出來。而後分析LUN在RAID組中的分配信息，以及LUN分配的數據塊MAP。因爲底層只有一個LUN，所以只須要分析一份LUN信息就OK了。而後根據這些信息使用北亞raid恢復(datahf.net)程序，解釋LUN的數據MAP並導出LUN的全部數據。
六、解釋ZFS文件系統並修復
利用北亞數據恢復(datahf.net自主開發的ZFS文件系統解釋程序對生成的LUN作文件系統解釋，發現程序在解釋某些文件系統元文件的時候報錯。迅速安排開發工程師對程序作debug調試，分析程序報錯緣由。接着安排文件系統工程師分析ZFS文件系統是否由於版本緣由，致使程序不支持。通過長達7小時的分析與調試，發現ZFS文件系統因存儲忽然癱瘓致使其中某些元文件損壞，從而致使解釋ZFS文件系統的程序沒法正常解釋。
上述分析明確了ZFS文件系統因存儲癱瘓致使部分文件系統元文件損壞，所以須要對這些損壞的文件系統元文件作修復，才能正常解析ZFS文件系統。分析損壞的元文件發現，因當初ZFS文件正在進行IO操做的同時存儲癱瘓，致使部分文件系統元文件沒有更新以及損壞。人工對這些損壞的元文件進行手工修復，保證ZFS文件系統可以正常解析。
七、導出全部數據
利用程序對修復好的ZFS文件系統作解析，解析全部文件節點及目錄結構。部分文件目錄截圖以下：

八、驗證最新數據
因爲數據都是文本類型及DCM圖片，須要搭建太多的環境。由用戶方工程師指點某些數據進行驗證，驗證結果都沒有問題，數據均完整。部分文件驗證以下: