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