服務器數據恢復環境：

新網企業郵件服務器;

組建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操作風險很大，做之前一定要看清楚提示，如果出錯信息異常，應選擇其他方案。

審核編輯：湯梓紅