EMC存儲Raid故障數據分析報告

一、故障描述
用戶的EMC FC AX-4存儲出現崩潰現象,整個存儲空間由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信息就OK了。然后根據這些信息使用北亞raid恢復(datahf.net)程序，解釋LUN的數據MAP并導出LUN的所有數據。
五、解釋ZFS文件系統并修復
1、解釋ZFS文件系統
利用北亞數據恢復(datahf.net)自主開發的ZFS文件系統解釋程序對生成的LUN做文件系統解釋，發現程序在解釋某些文件系統元文件的時候報錯。迅速安排開發工程師對程序做debug調試，分析程序報錯原因。接著安排文件系統工程師分析ZFS文件系統是否因為版本原因，導致程序不支持。經過長達7小時的分析與調試，發現ZFS文件系統因存儲突然癱瘓導致其中某些元文件損壞，從而導致解釋ZFS文件系統的程序無法正常解釋。
2、修復ZFS文件系統
上述分析明確了ZFS文件系統因存儲癱瘓導致部分文件系統元文件損壞，因此需要對這些損壞的文件系統元文件做修復，才能正常解析ZFS文件系統。分析損壞的元文件發現，因當初ZFS文件正在進行IO操作的同時存儲癱瘓，導致部分文件系統元文件沒有更新以及損壞。人工對這些損壞的元文件進行手工修復，保證ZFS文件系統能夠正常解析。
六、導出所有數據
利用程序對修復好的ZFS文件系統做解析，解析所有文件節點及目錄結構。部分文件目錄截圖如下：

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


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