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

POWEREDGE系列某型號服務器；

LINUX系統(tǒng)+RAID5。

服務器故障：

管理員執(zhí)行FSCK操作后LINUX系統(tǒng)無法MOUNT。

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

1、經(jīng)過北亞數(shù)據(jù)恢復工程師檢測，發(fā)現(xiàn)RAID5陣列沒有問題。但是執(zhí)行FSCK操作后超級塊及第1個塊組中的位圖、描述和根目錄均被垃圾日志填充，無法直接獲取到文件系統(tǒng)的所有信息。

2、根據(jù)現(xiàn)存的文件系統(tǒng)節(jié)點及殘留的日志區(qū)，還原出原來的超級塊。

3、通過分析還原出來的SUPERBLOCK，我們得知文件系統(tǒng)為EXT3，原日志節(jié)點為8。

4、根據(jù)磁盤結構分析出日志節(jié)點的起始位置得到其大小，然后反過來分析其INODE，得到根目錄節(jié)點。

5、根目錄區(qū)域中有500多個LBA已被垃圾日志填充，北亞數(shù)據(jù)恢復工程師從日志中還原根目錄記錄，還原其他第一個塊組內可能的INODE，然后結構化文件系統(tǒng)。

6、這個時候已經(jīng)可以在LINUX下進行MOUNT了，多數(shù)數(shù)據(jù)已經(jīng)可以讀取。但很多用戶需要的數(shù)據(jù)出錯，懷疑是在使用當中崩潰造成的。

7、按照EXT3的特點進行索引跟入，結果發(fā)現(xiàn)多數(shù)不可讀節(jié)點被日志垃圾填充。

8、北亞數(shù)據(jù)恢復工程師對日志文件進行分析。如果可以回溯，則直接生成好節(jié)點；如果日志無參考，則通過數(shù)據(jù)區(qū)結構進行分析。（本案例中所有目錄區(qū)均完好）

9、完成上述操作后，用戶需要的數(shù)據(jù)都完整恢復出來，本次數(shù)據(jù)恢復完成。