Linux reiserfs文件系統(tǒng)損壞后的數(shù)據(jù)恢復
[數(shù)據(jù)恢復故障描述]
一臺IBM X3850服務器，由4塊146G SAS硬盤組成RAID5作為存儲介質(zhì)，操作系統(tǒng)為SUSE LINUX，文件系統(tǒng)全部是reiserfs。
分析后得知：之前的硬盤數(shù)據(jù)組織結(jié)構(gòu)為: 一個不到100M的boot分區(qū)，后接一個271G的LVM卷，之后是2G的swap分區(qū)。LVM卷中直接劃分了一個reiserfs文件系統(tǒng)，作為根分區(qū)。
用戶在使用過程中，系統(tǒng)未知原因癱瘓。
重裝系統(tǒng)后，整個RAID邏輯卷變成了前面2G的boot與swap分區(qū)，后接271G的LVM卷，LVM卷中文件系統(tǒng)位置有個空的reiserfs超級塊。
要求恢復原來271G中文件系統(tǒng)里的所有用戶數(shù)據(jù)，數(shù)據(jù)分別是MYSQL數(shù)據(jù)庫、PGSQL數(shù)據(jù)庫、網(wǎng)站程序與網(wǎng)頁、單位OA系統(tǒng)里的所有辦公文檔。
[數(shù)據(jù)恢復分析]
1、通過對全盤reiserfs樹節(jié)點之間的關(guān)聯(lián)，確定了原來的reiserfs分區(qū)位置，以此斷定，原來存儲數(shù)據(jù)的文件系統(tǒng)前2G被覆蓋。
2、應該是用戶在安裝系統(tǒng)時錯誤地初始化了分區(qū)結(jié)構(gòu)，之后裝好系統(tǒng)后，發(fā)現(xiàn)無法導入LVM卷，曾做過reiserfsck試圖修復。
3、因reiserfs文件系統(tǒng)對文件系統(tǒng)里所有的文件(含目錄)線性化后，再以文件key生成B+樹，樹不斷增加節(jié)點，會導致樹的結(jié)構(gòu)整體拉展后向整個磁盤的數(shù)據(jù)區(qū)做平滑遷移，這樣，***節(jié)點通常不會放在文件系統(tǒng)的最前面。因根目錄的文件KEY號通常是最小的，所以，從空間上看，前2G中存儲最多的應該是從根起始路徑最近的key節(jié)點，這樣，用戶數(shù)據(jù)因目錄層次較深，節(jié)點存在的可能性很高。
4、前2G覆蓋的數(shù)據(jù)無法恢復，只能希望不要恰好覆蓋用戶數(shù)據(jù)。
5、因文件系統(tǒng)前面對整個樹的索引全丟失，加上reiserfs的樹概念設(shè)計得很抽象，重搭建樹會很困難。
[數(shù)據(jù)恢復過程]
1、通過自主程序在整個原文件系統(tǒng)區(qū)域進行key節(jié)點掃描，將所有節(jié)點導出。
2、通過自主程序?qū)λ腥~節(jié)點重新排序、過濾(去掉之前刪除文件丟棄的節(jié)點)，重新生成二級、三級、四級等葉節(jié)點。選擇分區(qū)前面2G空間做為新樹的結(jié)構(gòu)區(qū)(反正這部分數(shù)據(jù)是沒用的了，重裝系統(tǒng)已經(jīng)裝得滿滿的)，并生成對應地址信息。應對目錄命名問題，如遇到原樹路徑某節(jié)點丟失的情況，對其用自定義的key節(jié)點編號命名，如無法確定其父目錄，暫加入/otherfiles下。
3、根據(jù)上面對，生成樹索引信息，寫入特定位置，再根據(jù)這些信息，生成超級塊，設(shè)置clear標志。
4、在suse虛擬機下，創(chuàng)建快照，掛載修復好的卷，已經(jīng)可以看到文件了。(注：虛擬機與快照的目的為了操作可加溯，同時因bitmap等元數(shù)據(jù)不影響數(shù)據(jù)，未做修正，故掛載前不可做reiserfsck)。
5、在修復用的suse虛擬機下，掛載用于copy數(shù)據(jù)的目標硬盤，mkfs后將所有數(shù)據(jù)cp到目標盤。
6、用戶通過find命令整理所需數(shù)據(jù)，修正部分目錄文件位置與名稱。
7、部分丟失的散文件，按大小與文件頭標志查找，找到后移動及重命名。
[數(shù)據(jù)恢復結(jié)果]
1、所幸重要數(shù)據(jù)100%恢復成功。
2、樹的不直觀性加上程序的調(diào)試，使得整個恢復工作歷時3天之久，在繁亂的信息樹中跟來跟去，真是煩人得很，幸好撐下來了。
[隨筆]
繁鎖的數(shù)據(jù)恢復分析工作真不是人干的。
【編輯推薦】
