EMC存儲(chǔ)硬盤(pán)損壞的數(shù)據(jù)恢復(fù)全過(guò)程

北京某醫(yī)院EMC FC AX-4存儲(chǔ)崩潰,整個(gè)存儲(chǔ)空間由12塊1TB STAT的硬盤(pán)組成的，其中10塊硬盤(pán)組成一個(gè)RAID5的陣列，其余兩塊做成熱備硬盤(pán)使用。由于RAID5陣列中出現(xiàn)2塊硬盤(pán)損壞，而此時(shí)只有一塊熱備硬盤(pán)成功激活，因此導(dǎo)致RAID5陣列癱瘓，上層LUN無(wú)法正常使用。

由于存儲(chǔ)是因?yàn)槟承┐疟P(pán)掉線，從而導(dǎo)致整個(gè)存儲(chǔ)不可用。因此接收到磁盤(pán)以后先對(duì)所有磁盤(pán)做物理檢測(cè)，檢測(cè)完后發(fā)現(xiàn)沒(méi)有物理故障。接著使用壞道檢測(cè)工具檢測(cè)磁盤(pán)壞道，發(fā)現(xiàn)也沒(méi)有壞道。

考慮到數(shù)據(jù)的安全性以及可還原性，在做數(shù)據(jù)恢復(fù)之前需要對(duì)所有源數(shù)據(jù)做備份，以防萬(wàn)一其他原因?qū)е聰?shù)據(jù)無(wú)法再次恢復(fù)。使用winhex將所有磁盤(pán)都鏡像成文件，由于源磁盤(pán)的扇區(qū)大小為520字節(jié)，因此還需要使用特殊工具將所有備份的數(shù)據(jù)再做520 to 512字節(jié)的轉(zhuǎn)換。

1、分析故障原因

由于前兩個(gè)步驟并沒(méi)有檢測(cè)到磁盤(pán)有物理故障或者是壞道，由此推斷可能是由于某些磁盤(pán)讀寫(xiě)不穩(wěn)定導(dǎo)致故障發(fā)生。因?yàn)镋MC控制器檢查磁盤(pán)的策略很?chē)?yán)格，一旦某些磁盤(pán)性能不穩(wěn)定，EMC控制器就認(rèn)為是壞盤(pán)，就將認(rèn)為是壞盤(pán)的磁盤(pán)踢出RAID組。而一旦RAID組中掉線的盤(pán)到達(dá)到RAID級(jí)別允許掉盤(pán)的極限，那么這個(gè)RAID組將變得不可用，上層基于RAID組的LUN也將變得不可用。目前初步了解的情況為基于RAID組的LUN只有一個(gè)，分配給SUN小機(jī)使用，上層文件系統(tǒng)為ZFS。

2、分析RAID組結(jié)構(gòu)

EMC存儲(chǔ)的LUN都是基于RAID組的，因此需要先分析底層RAID組的信息，然后根據(jù)分析的信息重構(gòu)原始的RAID組。分析每一塊數(shù)據(jù)盤(pán)，發(fā)現(xiàn)8號(hào)盤(pán)和11號(hào)盤(pán)完全沒(méi)有數(shù)據(jù)，從管理界面上可以看到8號(hào)盤(pán)和11號(hào)盤(pán)都屬于Hot Spare，但8號(hào)盤(pán)的Hot Spare替換了5號(hào)盤(pán)的壞盤(pán)。因此可以判斷雖然8號(hào)盤(pán)的Hot Spare雖然成功激活，但由于RAID級(jí)別為RAID5，此時(shí)RAID組中還缺失一塊硬盤(pán)，所以導(dǎo)致數(shù)據(jù)沒(méi)有同步到8號(hào)硬盤(pán)中。繼續(xù)分析其他10塊硬盤(pán)，分析數(shù)據(jù)在硬盤(pán)中分布的規(guī)律，RAID條帶的大小，以及每塊磁盤(pán)的順序。

3、分析RAID組掉線盤(pán)

根據(jù)上述分析的RAID信息，嘗試通過(guò)RAID虛擬程序?qū)⒃嫉腞AID組虛擬出來(lái)。但由于整個(gè)RAID組中一共掉線兩塊盤(pán)，因此需要分析這兩塊硬盤(pán)掉線的順序。仔細(xì)分析每一塊硬盤(pán)中的數(shù)據(jù)，發(fā)現(xiàn)有一塊硬盤(pán)在同一個(gè)條帶上的數(shù)據(jù)和其他硬盤(pán)明顯不一樣，因此初步判斷此硬盤(pán)可能是最先掉線的，通過(guò)RAID校驗(yàn)程序?qū)@個(gè)條帶做校驗(yàn)，發(fā)現(xiàn)除掉剛才分析的那塊硬盤(pán)得出的數(shù)據(jù)是最好的，因此可以明確最先掉線的硬盤(pán)了。

4、分析RAID組中的LUN信息

由于LUN是基于RAID組的，因此需要根據(jù)上述分析的信息將RAID組重組出來(lái)。然后分析LUN在RAID組中的分配信息，以及LUN分配的數(shù)據(jù)塊MAP。由于底層只有一個(gè)LUN，因此只需要分析一份LUN信息就OK了。然后根據(jù)這些信息使用raid恢復(fù)程序，解釋LUN的數(shù)據(jù)MAP并導(dǎo)出LUN的所有數(shù)據(jù)。

1、解釋ZFS文件系統(tǒng)

利用ZFS文件系統(tǒng)解釋程序?qū)ι傻腖UN做文件系統(tǒng)解釋，發(fā)現(xiàn)程序在解釋某些文件系統(tǒng)源文件的時(shí)候報(bào)錯(cuò)。迅速安排開(kāi)發(fā)工程師對(duì)程序做debug調(diào)試，分析程序報(bào)錯(cuò)原因。接著安排文件系統(tǒng)工程師分析ZFS文件系統(tǒng)是否因?yàn)榘姹驹?，?dǎo)致程序不支持。經(jīng)過(guò)長(zhǎng)達(dá)7小時(shí)的分析與調(diào)試，發(fā)現(xiàn)ZFS文件系統(tǒng)因存儲(chǔ)突然癱瘓導(dǎo)致其中某些元文件損壞，從而導(dǎo)致解釋ZFS文件系統(tǒng)的程序無(wú)法正常解釋。

2、修復(fù)ZFS文件系統(tǒng)

上述分析明確了ZFS文件系統(tǒng)因存儲(chǔ)癱瘓導(dǎo)致部分文件系統(tǒng)元文件損壞，因此需要對(duì)這些損壞的文件系統(tǒng)元文件做修復(fù)，才能正常解析ZFS文件系統(tǒng)。分析損壞的元文件發(fā)現(xiàn)，因當(dāng)初ZFS文件正在進(jìn)行IO操作的同時(shí)存儲(chǔ)癱瘓，導(dǎo)致部分文件系統(tǒng)元文件沒(méi)有更新以及損壞。人工對(duì)這些損壞的元文件進(jìn)行手工修復(fù)，保證ZFS文件系統(tǒng)能夠正常解析。

利用程序?qū)π迯?fù)好的ZFS文件系統(tǒng)做解析，解析所有文件節(jié)點(diǎn)及目錄結(jié)構(gòu)。

由于數(shù)據(jù)都是文本類型及DCM圖片，需要搭建太多的環(huán)境。由用戶方工程師指點(diǎn)某些數(shù)據(jù)進(jìn)行驗(yàn)證，驗(yàn)證結(jié)果都沒(méi)有問(wèn)題，數(shù)據(jù)均完整。