IBM X3650M3儲存raid陣列癱瘓的恢復過程

北亞資料恢復中心發表於2018-08-01

儲存資料恢復故障情況:

北京某公司的一臺IBM X3650M3儲存由於未知原因崩潰,管理員排查故障時發現儲存中有兩塊硬碟離線導致該組陣列無法使用,儲存內資料丟失,需要進行raid陣列資料恢復。

Raid5陣列資料恢復檢測:

資料恢復工程師趕到客戶現場對raid陣列中的磁碟進行資料恢復檢測發現該raid中離線的兩塊硬碟均沒有硬體問題,直接進行raid陣列資料恢復操作即可。

Raid5陣列資料恢復過程:

1.資料恢復工程師首先將客戶的raid陣列中所有磁碟使用資料恢復工具進行映象備份,備份檔案儲存至資料恢復平臺上,然後將客戶的原儲存中所有磁碟還原到原始狀態交還客戶,隨後的資料恢復操作均在資料恢復平臺中進行操作,以保障客戶原始資料不被修改和破壞。
2.伺服器資料恢復工程師對原raid陣列的映象檔案進行了仔細分析發現該raid陣列中有兩塊熱備盤,硬碟離線時只有一塊熱備盤成功啟用,此時raid5陣列仍然處於缺盤狀態,資料並未同步。於是工程師開始分析原raid陣列中的硬碟分佈規律和raid條帶資訊、盤序資訊等,以便在後期的資料恢復工作中可以通過這些資訊重組raid陣列,恢復資料。
3.根據上述分析的RAID資訊,仔細分析每一塊硬碟中的資料,發現有一塊硬碟在同一個條帶上的資料和其他硬碟明顯不一樣,因此初步判斷此硬碟可能是最先掉線的,工程師使用一款自用的RAID校驗程式對這個條帶進行校驗發現除掉剛才分析的那塊硬碟得出的資料是最好的,因此可以明確最先掉線的硬碟了。
4.資料恢復工程師根據分析來的raid資訊重組raid陣列,再通過重組出的raid陣列分析lun的分配和資料塊情況,在使用資料恢復軟體匯出lun並解析檔案系統時檔案系統提示報錯,工程師重新除錯資料恢復軟體後報錯情況依然存在,可以排除軟體故障導致檔案系統解析報錯,於是對匯出的檔案進行手動檢查發現導致資料恢復軟體解析報錯的原因為檔案系統元檔案損壞導致軟體無法自動解析而報錯。出現這種情況的原因可能是因為儲存癱瘓時zfs檔案正在進行IO操作,導致的檔案系統元檔案沒有更新和元檔案損壞(後來證明的確如此)。由於資料恢復軟體無法繼續解析檔案系統,只好由工程師手動進行zfs檔案系統中損壞的元檔案進行修復後再進行解析。
5.將修復好的檔案系統再次使用資料恢復軟體進行解析,成功解析所有檔案節點和檔案目錄結構,將資料匯出。

Raid5資料恢復結果:

使用者在資料恢復平臺上對匯出的資料進行驗證,資料恢復成功。

 

相關文章