條帶 分享 成功 問題 陣列 管理 排查 ima 51cto

存儲數據恢復故障情況：

北京某公司的一臺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數據恢復結果：

用戶在數據恢復平臺上對導出的數據進行驗證，數據恢復成功。

北京某公司IBM X3650M3存儲崩潰的解決過程