您好,登錄后才能下訂單哦!
服務器故障描述:
山西某公司一臺服務器的EMC FC AX-4存儲RAID5磁盤陣列,陣列中共有12塊硬盤組成raid5磁盤陣列其中有兩塊硬盤為熱備盤,陣列中硬盤單盤容量為1TB,服務器中有兩塊硬盤離線,一塊熱備盤未啟用。客戶將服務器中所有磁盤帶到數據恢復公司。
通常情況下造成服務器硬盤離線的原因為磁盤物理故障或者硬盤壞道。但是由于EMC控制器有著十分嚴格的磁盤檢查策略,容易將性能不穩定的硬盤判定為硬件故障提出raid組,所以導致服務器崩潰的原因也有可能是磁盤讀寫不穩定。
服務器數據恢復解決過程:
第一步:檢測硬盤和服務器數據備份;對服務器中所有磁盤進行物理故障檢測,硬盤沒有物理故障,然后使用壞道檢測工具進行硬盤壞道排查也一切正常。使用專業鏡像工具將raid中所有磁盤做全盤鏡像。如下圖:
第二步:分析RAID組結構;Raid數據恢復的常規步驟先要對服務器raid信息進行分析,然后重構raid組。在本案例中分析發現作為熱備盤的6號盤和9號盤全部無數據,6號盤已經成功激活并替換了磁盤陣列中的5號硬盤,但數據并未同步。繼續對該服務器raid中的其他硬盤進行條帶大小、數據的分布規律、磁盤順序等必要信息進行分析。分析發現7號硬盤在同一條帶上的數據與該raid中其他硬盤不同,初步確認該盤為掉線較早的硬盤,使用數據恢復公司自用的raid校驗程序對此條帶進行校驗發現最好的數據就是除去7號盤以后的數據,所以7號盤為先掉線盤無疑。將分析出來的上述信息通過北亞自主研發的raid虛擬程序組建出原raid磁盤陣列。
第三步:對服務器磁盤陣列中的LUN信息進行分析;該服務器底層只分配了一個LUN,所以工作量相對小很多,只需對一個lun的信息進行分析,分析后使用raid恢復程序記性解釋map數據并導出。然后使用自用軟件進行zfs文件系統解釋,某些文件系統文件在解析時報錯。工程師只好手動對程序做debug調試后發現報錯原因為服務器突然癱瘓導致某些元文件損壞,現有程序無法正常解釋。因此需要對這些損壞的文件系統元文件做修復,才能正常解析ZFS文件系統。分析損壞的元文件發現,因當初ZFS文件正在進行IO操作的同時存儲癱瘓,導致部分文件系統元文件沒有更新以及損壞。人工對這些損壞的元文件進行手工修復,保證ZFS文件系統能夠正常解析。
第四步:導出所有成功恢復數據;利用程序對修復好的ZFS文件系統做解析,解析所有文件節點及目錄結構。對所有成功恢復的數據進行驗證,數據完整。部分文件目錄和驗證截圖如下:
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。