服務器數據恢復成功案例

[數據修復常見故障敘述]
一臺IBMX3850網絡服務器，由4塊146GSAS電腦硬盤構成RAID5做為移動存儲設備，電腦操作系統為SUSELINUX，系統文件所有是reiserfs。
剖析后獲知：以前的硬盤數據組織架構為:一個不上100M的boot系統分區，后接一個272GB的LVM卷，以后是2G的swap系統分區。LVM卷中立即區劃了一個reiserfs文件系統軟件，做為根系統分區。
客戶在應用全過程中，系統軟件不明緣故偏癱。
重做系統后，全部RAID邏輯性卷變成了前邊2G的boot與swap系統分區，后接272GB的LVM卷，LVM卷中系統文件部位有一個空的reiserfs非常塊。
規定修復原先272GB中系統文件里的全部客戶數據信息，數據信息分別是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、在susevm虛擬機下，建立快照更新，初始化修補好的卷，早已能夠 見到文檔了。(注：vm虛擬機與快照更新的目地以便實際操作可加溯，另外因bitmap等數據庫不危害數據信息，未做調整，故初始化前不能做reiserfsck)。
5、在修補用的susevm虛擬機下，初始化用以copy數據信息的總體目標電腦硬盤，mkfs后將全部數據信息cp到總體目標盤。
6、客戶根據find指令梳理所需數據信息，調整一部分文件目錄文檔部位與名字。
7、一部分遺失的散文檔，按尺寸與文件頭標示搜索，尋找后挪動及重新命名。
[數據修復結果]
關鍵數據信息100%修復取得成功。