服務器數(shù)據(jù)恢復環(huán)境：

新網(wǎng)企業(yè)郵件服務器;

組建RAID5，文件系統(tǒng)為REISERFS;

一個數(shù)據(jù)分區(qū)，存放上百萬企業(yè)用戶的郵件。

服務器故障&分析：

服務器在正常運行過程中，RAID突然OFFLINE。管理員檢查發(fā)現(xiàn)故障服務器有兩塊盤報警，將其中一塊盤強制上線后卻發(fā)現(xiàn)卷無法掛載，于是執(zhí)行FSCK并REBULD TREE，完成上述操作后卷仍然無法掛載。咨詢多家數(shù)據(jù)恢復服務商均無法提供可行的解決方案，最終新網(wǎng)選擇我們數(shù)據(jù)恢復中心進行數(shù)據(jù)恢復。

這種RAID故障在我們數(shù)據(jù)恢復中心接到的cases中是很常見的。因為報警的兩塊盤并不是同時掉線，如果強制上線先離線的硬盤會導致數(shù)據(jù)區(qū)的新舊數(shù)據(jù)混在一起，文件系統(tǒng)結(jié)構不一致。強制上線會在讀寫過程中生成新的檢驗條帶，會影響一部分數(shù)據(jù)。如果讀寫不多或根本無法MOUNT，情況的嚴重性會小很多。

本案例中最嚴重的問題在于REBUILD TREE，此操作相當于將一個混雜的文件系統(tǒng)連續(xù)化，結(jié)果會導致文件系統(tǒng)的所有結(jié)構體全面出錯，這種情況通常是無法挽救的。加上用戶的文件目錄結(jié)構非常復雜，文件總數(shù)粗略估計上億，恢復數(shù)據(jù)的機會很小。

服務器數(shù)據(jù)恢復過程：

1、首先對故障服務器所有硬盤做鏡像備份，后續(xù)的數(shù)據(jù)恢復操作都在備份文件上進行，避免對數(shù)據(jù)二次破壞。

2、服務器數(shù)據(jù)恢復工程師先試圖將文件系統(tǒng)結(jié)構區(qū)單獨提出來進行分析，但REISERFS文件系統(tǒng)區(qū)相對分散且無規(guī)律，通過北亞自主研發(fā)的程序?qū)ξ募到y(tǒng)結(jié)構區(qū)進行提取和分析。在本案例中，僅1級節(jié)點提取出來的數(shù)據(jù)就有好幾個G，可見本案例文件結(jié)構的復雜。

3、對文件系統(tǒng)區(qū)進行一致性檢驗，修正錯誤地方。本案例中好多文件系統(tǒng)節(jié)點區(qū)都因檢驗關系，使關鍵屬性字節(jié)發(fā)生了改變。通過北亞自主研發(fā)的程序?qū)⑺泄?jié)點狀態(tài)統(tǒng)一初始化，對節(jié)點進行一致性處理。

4、完成上述兩步操作后有2種方案恢復最終的數(shù)據(jù)：

第一種方案：在LINUX系統(tǒng)下再次執(zhí)行FSCK，結(jié)果實施這種方案后發(fā)現(xiàn)效果不好，原因是LINUX FSCK的功能有限，如果在父節(jié)點稍有錯誤，其子節(jié)點便會被全部打入到LOST+FOUND里，無法還原原本的目錄結(jié)構。

第二種方案：通過只讀方式，在WINDOWS環(huán)境下用北亞自主研發(fā)的程序提取數(shù)據(jù)。在具體的實施過程中，需要不斷修改程序并忽略一些錯誤，最終提取出數(shù)據(jù)。

5、由用戶對恢復出來的數(shù)據(jù)進行檢測，確認需要的數(shù)據(jù)基本都恢復出來，可以正常讀取。

服務器數(shù)據(jù)恢復總結(jié)：

RAID5磁盤陣列兩塊硬盤先后離線，但是又不知道離線先后順序的case很多。碰到這種情況需要我們謹慎處理。如果可以查詢到日志，通過日志確定為好。如果強制上線出錯，應馬上停止操作，切不可做FSCK等操作。

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

審核編輯：湯梓紅