EMC存儲Raid故障數(shù)據(jù)分析報告

目錄一、故障描述 2二、檢測磁盤 3三、備份數(shù)據(jù) 3四、故障分析及恢復過程 31、分析故障原因 32、分析RAID組結(jié)構(gòu) 33、分析RAID組掉線盤 44、分析RAID組中的LUN信息 4五、解釋ZFS文件系統(tǒng)并修復 41、解釋ZFS文件系統(tǒng) 42、修復ZFS文件系統(tǒng) 4六、導出所有數(shù)據(jù) 5七、驗證最新數(shù)據(jù) 5八、數(shù)據(jù)恢復結(jié)論 6

一、故障描述用戶的EMCFCAX-4存儲出現(xiàn)崩潰現(xiàn)象,整個存儲空間由12塊1TBSTAT的硬盤組成的，其中10塊硬盤組成一個RAID5的陣列，其余兩塊做成熱備盤使用。由于RAID5陣列中出現(xiàn)2塊硬盤損壞，而此時只有一塊熱備盤成功激活，因此導致RAID5陣列癱瘓，上層LUN無法正常使用。

二、檢測磁盤由于存儲是因為某些磁盤掉線，從而導致整個存儲不可用。因此接收到磁盤以后先對所有磁盤做物理檢測，檢測完后發(fā)現(xiàn)沒有物理故障。接著使用壞道檢測工具檢測磁盤壞道，發(fā)現(xiàn)也沒有壞道。三、備份數(shù)據(jù)考慮到數(shù)據(jù)的安全性以及可還原性，在做數(shù)據(jù)恢復之前需要對所有源數(shù)據(jù)做備份，以防萬一其他原因?qū)е聰?shù)據(jù)無法再次恢復。使用winhex將所有磁盤都鏡像成文件，由于源磁盤的扇區(qū)大小為520字節(jié)，因此還需要使用特殊工具將所有備份的數(shù)據(jù)再做520to512字節(jié)的轉(zhuǎn)換。四、故障分析及恢復過程1、分析故障原因由于前兩個步驟并沒有檢測到磁盤有物理故障或者是壞道，由此推斷可能是由于某些磁盤讀寫不穩(wěn)定導致故障發(fā)生。因為EMC控制器檢查磁盤的策略很嚴格，一旦某些磁盤性能不穩(wěn)定，EMC控制器就認為是壞盤，就將認為是壞盤的磁盤踢出RAID組。而一旦RAID組中掉線的盤到達到RAID級別允許掉盤的極限，那么這個RAID組將變的不可用，上層基于RAID組的LUN也將變的不可用。目前初步了解的情況為基于RAID組的LUN只有一個，分配給SUN小機使用，上層文件系統(tǒng)為ZFS。2、分析RAID組結(jié)構(gòu)EMC存儲的LUN都是基于RAID組的，因此需要先分析底層RAID組的信息，然后根據(jù)分析的信息重構(gòu)原始的RAID組。分析每一塊數(shù)據(jù)盤，發(fā)現(xiàn)8號盤和11號盤完全沒有數(shù)據(jù)，從管理界面上可以看到8號盤和11號盤都屬于HotSpare，但8號盤的HotSpare替換了5號盤的壞盤。因此可以判斷雖然8號盤的HotSpare雖然成功激活，但由于RAID級別為RAID5，此時RAID組中還缺失一塊硬盤，所以導致數(shù)據(jù)沒有同步到8號硬盤中。繼續(xù)分析其他10塊硬盤，分析數(shù)據(jù)在硬盤中分布的規(guī)律，RAID條帶的大小，以及每塊磁盤的順序。3、分析RAID組掉線盤根據(jù)上述分析的RAID信息，嘗試通過北亞自主開發(fā)的RAID虛擬程序?qū)⒃嫉腞AID組虛擬出來。但由于整個RAID組中一共掉線兩塊盤，因此需要分析這兩塊硬盤掉線的順序。仔細分析每一塊硬盤中的數(shù)據(jù)，發(fā)現(xiàn)有一塊硬盤在同一個條帶上的數(shù)據(jù)和其他硬盤明顯不一樣，因此初步判斷此硬盤可能是最先掉線的，通過北亞自主開發(fā)的RAID校驗程序?qū)@個條帶做校驗，發(fā)現(xiàn)除掉剛才分析的那塊硬盤得出的數(shù)據(jù)是最好的，因此可以明確最先掉線的硬盤了。4、分析RAID組中的LUN信息由于LUN是基于RAID組的，因此需要根據(jù)上述分析的信息將RAID組重組出來。然后分析LUN在RAID組中的分配信息，以及LUN分配的數(shù)據(jù)塊MAP。由于底層只有一個LUN，因此只需要分析一份LUN信息就OK了。然后根據(jù)這些信息使用北亞raid恢復()程序，解釋LUN的數(shù)據(jù)MAP并導出LUN的所有數(shù)據(jù)。五、解釋ZFS文件系統(tǒng)并修復1、解釋ZFS文件系統(tǒng)利用北亞數(shù)據(jù)恢復()自主開發(fā)的ZFS文件系統(tǒng)解釋程序?qū)ι傻腖UN做文件系統(tǒng)解釋，發(fā)現(xiàn)程序在解釋某些文件系統(tǒng)元文件的時候報錯。迅速安排開發(fā)工程師對程序做debug調(diào)試，分析程序報錯原因。接著安排文件系統(tǒng)工程師分析ZFS文件系統(tǒng)是否因為版本原因，導致程序不支持。經(jīng)過長達7小時的分析與調(diào)試，發(fā)現(xiàn)ZFS文件系統(tǒng)因存儲突然癱瘓導致其中某些元文件損壞，從而導致解釋ZFS文件系統(tǒng)的程序無法正常解釋。2、修復ZFS文件系統(tǒng) 上述分析明確了ZFS文件系統(tǒng)因存儲癱瘓導致部分文件系統(tǒng)元文件損壞，因此需要對這些損壞的文件系統(tǒng)元文件做修復，才能正常解析ZFS文件系統(tǒng)。分析損壞的元文件發(fā)現(xiàn)，因當初ZFS文件正在進行IO操作的同時存儲癱瘓，導致部分文件系統(tǒng)元文件沒有更新以及損壞。人工對這些損壞的元文件進行手工修復，保證ZFS文件系統(tǒng)能夠正常解析。六、導出所有數(shù)據(jù)利用程序?qū)π迯秃玫腪FS文件系統(tǒng)做解析，解析所有文件節(jié)點及目錄結(jié)構(gòu)。部分文件目錄截圖如下：七、驗證最新數(shù)據(jù) 由于數(shù)據(jù)都是文本類型及DCM圖片，需要搭建太多的環(huán)境。由用戶方工程師指點某些數(shù)據(jù)進行驗證，驗證結(jié)果都沒有問題，數(shù)據(jù)均完整。部分文件驗證如下:八、數(shù)據(jù)恢復結(jié)論由