【伺服器資料恢復】REISERFS檔案系統RAID5崩潰的資料恢復案例

伺服器資料恢復環境：

新網企業郵件伺服器；

組建RAID5，檔案系統為REISERFS；

一個資料分割槽，存放上百萬企業使用者的郵件。

伺服器故障&分析：

伺服器在正常執行過程中，RAID突然OFFLINE。管理員檢查發現故障伺服器有兩塊盤報警，將其中一塊盤強制上線後卻發現

卷無法掛載，於是執行FSCK並REBULD TREE，完成上述操作後卷仍然無法掛載。諮詢多家資料恢復服務商均無法提供可行的

解決方案，最終新網選擇我們資料恢復中心進行資料恢復。

這種RAID故障在我們資料恢復中心接到的cases中是很常見的。因為報警的兩塊盤並不是同時掉線，如果強制上線先離線的硬

盤會導致資料區的新舊資料混在一起，檔案系統結構不一致。強制上線會在讀寫過程中生成新的檢驗條帶，會影響一部分資料

。如果讀寫不多或根本無法MOUNT，情況的嚴重性會小很多。

本案例中最嚴重的問題在於REBUILD TREE，此操作相當於將一個混雜的檔案系統連續化，結果會導致檔案系統的所有結構體

全面出錯，這種情況通常是無法挽救的。加上使用者的檔案目錄結構非常複雜，檔案總數粗略估計上億，恢復資料的機會很小。

伺服器資料恢復過程：    

1、首先對故障伺服器所有硬碟做映象備份，後續的資料恢復操作都在備份檔案上進行，避免對資料二次破壞。

2、伺服器資料恢復工程師先試圖將檔案系統結構區單獨提出來進行分析，但REISERFS檔案系統區相對分散且無規律，透過

北亞自主研發的程式對檔案系統結構區進行提取和分析。在本案例中，僅1級節點提取出來的資料就有好幾個G，可見本案例

檔案結構的複雜。

3、對檔案系統區進行一致性檢驗，修正錯誤地方。本案例中好多檔案系統節點區都因檢驗關係，使關鍵屬性位元組發生了改變

。透過北亞自主研發的程式將所有節點狀態統一初始化，對節點進行一致性處理。

4、完成上述兩步操作後有2種方案恢復最終的資料：

第一種方案：在LINUX系統下再次執行FSCK，結果實施這種方案後發現效果不好，原因是LINUX FSCK的功能有限，如果在

父節點稍有錯誤，其子節點便會被全部打入到LOST+FOUND裡，無法還原原本的目錄結構。

第二種方案：透過只讀方式，在WINDOWS環境下用北亞自主研發的程式提取資料。在具體的實施過程中，需要不斷修改程

序並忽略一些錯誤，最終提取出資料。

5、由使用者對恢復出來的資料進行檢測，確認需要的資料基本都恢復出來，可以正常讀取。

伺服器資料恢復總結：

RAID5磁碟陣列兩塊硬碟先後離線，但是又不知道離線先後順序的case很多。碰到這種情況需要我們謹慎處理。如果可以查

詢到日誌，透過日誌確定為好。如果強制上線出錯，應馬上停止操作，切不可做FSCK等操作。

LINUX的FSCK操作風險很大，做之前一定要看清楚提示，如果出錯資訊異常，應選擇其他方案。