解決Reiserfs檔案系統損壞的問題我們是認真的

一、故障裝置資訊：

伺服器： X3850 伺服器

硬碟型別：SAS ，容量： 146G    4 塊硬碟組成 RAID5

檔案系統：R eiserfs

二、 R eiserfs 檔案系統 故障分析：

1 、 經過分析發現了之前的硬碟資料組織結構是由一個不到100M 的 boot 分割槽，後接一個 271G 的 LVM 卷，之後是 2G 的 swap 分割槽。 LVM 卷中直接劃分了一個 reiserfs 檔案系統，作為根分割槽。

2 、 使用者在使用的過程中，系統遭遇了未知的原因而癱瘓，經過系統的衝撞以後發現整個RAID 邏輯卷變成了前面 2G 的 boot 與 swap 分割槽，後接 271G 的 LVM 卷， LVM 卷中檔案系統位置有個空的 reiserfs 超級塊。

3 、 我們這次要恢復的資料就是原來271G 中檔案系統裡的所有使用者資料，這些資料包含了資料庫、網站程式與網頁、單位 OA 系統裡的所有辦公文件。

 

三、 R eiserfs 檔案系統 解決方案：

1 、 先通過對全盤reiserfs 樹節點之間的關聯確定了原來的 reiserfs 分割槽位置，發現原來儲存資料的檔案系統的前 2G 資料已經被覆蓋， 判斷 應該是使用者在安裝系統時錯誤地初始化了分割槽結構，所以裝好系統無法匯入LVM 卷而做過 reiserfsck 試圖修復。

2 、 因reiserfs 檔案系統對檔案系統裡所有的檔案 ( 含目錄 ) 線性化後，再以檔案 key 生成 B+ 樹，樹不斷增加節點會導致樹的結構整體拉展後向整個磁碟的資料區做平滑遷移。這樣一來頂級節點通常不會放在檔案系統的最前面。因根目錄的檔案 KEY 號通常是最小的，所以，從空間上看，前 2G 中儲存最多的應該是從根起始路徑最近的 key 節點 。

3 、 這樣，使用者資料因目錄層次較深，節點存在的可能性很高。前2G 覆蓋的資料已經無法恢復，只能希望不要恰好覆蓋使用者資料。因檔案系統前面對整個樹的索引全丟失，加上 reiserfs 的樹概念設計得很抽象，重搭建樹會很困難。

4、 我們通過自主程式在整個原檔案系統區域進行key 節點掃描並將所有節點匯出。然後通過自主程式對所有葉節點重新排序、過濾 ( 去掉之前刪除檔案丟棄的節點 ) ，重新生成二級、三級、四級等葉節點。選擇分割槽前面 2G 空間做為新樹的結構區，並生成對應地址資訊。

5、 應對目錄命名問題，如遇到原樹路徑某節點丟失的情況，對其用自定義的key 節點編號命名，如無法確定其父目錄，暫加入 /otherfiles 下。根據上面對，生成樹索引資訊，寫入特定位置，再根據這些資訊，生成超級塊，設定 clear 標誌。在 suse 虛擬機器下，建立快照，掛載修復好的卷，已經可以看到檔案了。 ( 注：虛擬機器與快照的目的為了操作可加溯，同時因 bitmap 等後設資料不影響資料，未做修正，故掛載前不可做 reiserfsck) 。

6、 在修復用的suse 虛擬機器下，掛載用於 copy 資料的目標硬碟， mkfs 後將所有資料 cp 到目標盤。使用者通過 find 命令整理所需資料，修正部分目錄檔案位置與名稱。部分丟失的散檔案，按大小與檔案頭標誌查詢，找到後移動及重新命名。

 

四、 R eiserfs 檔案系統 資料恢復結果：

    經工程師處理分析後，資料已成功恢復，且均可正常使用，至此資料恢復工作結束。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31380569/viewspace-2669191/，如需轉載，請註明出處，否則將追究法律責任。