一、故障描述
1、裝置清單
| 裝置名稱 | 裝置型号 | 數量 |
| EMC FC存儲 | AX-4 | 1 |
| 1T STAT硬碟 | 12 |
2、故障描述
整個存儲空間由12塊1TB STAT的硬碟組成的，其中10塊硬碟組成一個RAID5的陣列，其餘兩塊做成熱備盤使用。由于RAID5陣列中出現2塊硬碟損壞，而此時隻有一塊熱備盤成功激活，是以導緻RAID5陣列癱瘓，上層LUN無法正常使用。
二、檢測磁盤
由于存儲是因為某些磁盤掉線，進而導緻整個存儲不可用。是以接收到磁盤後，先對所有磁盤做實體檢測，檢測完後發現沒有實體故障。接着使用壞道檢測工具檢測磁盤壞道，發現也沒有壞道。磁盤壞道檢測日志如下圖：
三、備份資料
考慮到資料的安全性以及可還原性，在做資料恢複之前需要對所有源資料做備份，以防其他原因導緻資料無法再次恢複。使用winhex将所有磁盤都鏡像成檔案，由于源磁盤的扇區大小為520位元組，是以還需要使用特殊工具将所有備份的資料再做520 to 512位元組的轉換。備份完部分資料如下圖：
四、故障分析
1、分析故障原因
由于前兩個步驟并沒有檢測到磁盤有實體故障或者壞道，由此推斷，可能由于某些磁盤讀寫不穩定導緻故障發生。因為EMC控制器檢查磁盤的政策很嚴格，一旦某些磁盤性能不穩定，EMC控制器就認為是壞盤，就将認為是壞盤的磁盤踢出RAID組。而一旦RAID組中掉線的盤到達到RAID級别允許掉盤的極限，那麼這個RAID組将變的不可用，上層基于RAID組的LUN也将變的不可用。目前初步了解的情況為基于RAID組的LUN隻有一個，配置設定給SUN小機使用，上層檔案系統為ZFS。
2、分析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條帶的大小，以及每塊磁盤的順序。
3、分析RAID組掉線盤
根據上述分析的RAID資訊，嘗試通過北亞自主開發的RAID虛拟程式将原始的RAID組虛拟出來。但由于整個RAID組中一共掉線兩塊盤，是以需要分析這兩塊硬碟掉線的順序。仔細分析每一塊硬碟中的資料，發現有一塊硬碟在同一個條帶上的資料和其他硬碟明顯不一樣，初步判斷此硬碟可能是最先掉線的，通過北亞自主開發的RAID校驗程式對這個條帶做校驗，發現除掉剛才分析的那塊硬碟得出的資料是最好的，更加确定最先掉線的硬碟了。
4、分析RAID組中的LUN資訊
LUN是基于RAID組的，是以需要根據上述分析的資訊将RAID組重組出來。然後分析LUN在RAID組中的配置設定資訊，以及LUN配置設定的資料塊MAP。由于底層隻有一個LUN，是以隻需要分析一份LUN資訊。然後根據這些資訊編寫相應的程式，解釋LUN的資料塊MAP并導出LUN的所有資料。
五、解釋ZFS檔案系統并修複
1、解釋ZFS檔案系統
利用北亞自主開發的ZFS檔案系統解釋程式對生成的LUN做檔案系統解釋，發現程式在解釋某些檔案系統源檔案的時候報錯。迅速安排開發工程師對程式做Debug調試，分析程式報錯原因。接着安排檔案系統工程師分析ZFS檔案系統是否因為版本原因，導緻程式不支援。經過長達7小時的分析與調試，發現ZFS檔案系統因存儲突然癱瘓導緻其中某些源檔案損壞，進而導緻解釋ZFS檔案系統的程式無法正常解釋。
2、修複ZFS檔案系統
上述分析明确了ZFS檔案系統因存儲癱瘓導緻部分檔案系統源檔案損壞，是以需要對這些損壞的檔案系統源檔案做修複，才能正常解析ZFS檔案系統。分析損壞的源檔案發現，因當初ZFS檔案正在進行IO操作的同時存儲癱瘓，導緻部分檔案系統源檔案沒有更新,并被損壞。人工對這些損壞的源檔案進行手工修複，保證ZFS檔案系統能夠正常解析。
六、恢複所有資料
利用程式對修複好的ZFS檔案系統做解析，解析所有檔案節點及目錄結構。部分檔案目錄截圖如下：
七、驗證最新資料
資料都是文本類型及DCM圖檔，是以不需要搭建太多的環境。由使用者方工程師指點某些資料驗證，驗證結果都沒有問題，資料均完整。部分檔案驗證如下:
八、移交資料
使用使用者方提供3塊2T的STAT硬碟，将恢複的所有資料均拷貝到這些硬碟中，資料恢複的總容量為5T左右。
九、資料恢複結論
由于故障發生後儲存現場環境良好，沒做相關危險的操作，對後期的資料恢複有很大的幫助。整個資料恢複過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間内完成整個資料恢複，恢複的資料使用者方也相當滿意。