在介紹恢複過程之前先簡單說明一下故障情況,發生故障的是一台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系統裡的所有辦公文檔。
我們先通過對全盤reiserfs樹節點之間的關聯确定了原來的reiserfs分區位置,發現原來存儲資料的檔案系統的前2G資料已經被覆寫,應該是使用者在安裝系統時錯誤地初始化了分區結構,是以裝好系統無法導入LVM卷而做過reiserfsck試圖修複。因reiserfs檔案系統對檔案系統裡所有的檔案(含目錄)線性化後,再以檔案key生成B+樹,樹不斷增加節點會導緻樹的結構整體拉展後向整個磁盤的資料區做平滑遷移。這樣一來頂級節點通常不會放在檔案系統的最前面。因根目錄的檔案KEY号通常是最小的,是以,從空間上看,前2G中存儲最多的應該是從根起始路徑最近的key節點,這樣,使用者資料因目錄層次較深,節點存在的可能性很高。前2G覆寫的資料已經無法恢複,隻能希望不要恰好覆寫使用者資料。因檔案系統前面對整個樹的索引全丢失,加上reiserfs的樹概念設計得很抽象,重搭建樹會很困難。
<a href="https://s2.51cto.com/wyfs02/M01/8F/A3/wKiom1jnRQyz3Cc7AAIxcGqLMJY507.jpg" target="_blank"></a>
我們通過自主程式在整個原檔案系統區域進行key節點掃描并将所有節點導出。然後通過自主程式對所有葉節點重新排序、過濾(去掉之前删除檔案丢棄的節點),重新生成二級、三級、四級等葉節點。選擇分區前面2G空間做為新樹的結構區(反正這部分資料是沒用的了,重裝系統已經裝得滿滿的),并生成對應位址資訊。應對目錄命名問題,如遇到原樹路徑某節點丢失的情況,對其用自定義的key節點編号命名,如無法确定其父目錄,暫加入/otherfiles下。根據上面對,生成樹索引資訊,寫入特定位置,再根據這些資訊,生成超級塊,設定clear标志。在suse虛拟機下,建立快照,挂載修複好的卷,已經可以看到檔案了。(注:虛拟機與快照的目的為了操作可加溯,同時因bitmap等中繼資料不影響資料,未做修正,故挂載前不可做reiserfsck)。在修複用的suse虛拟機下,挂載用于copy資料的目标硬碟,mkfs後将所有資料cp到目标盤。使用者通過find指令整理所需資料,修正部分目錄檔案位置與名稱。部分丢失的散檔案,按大小與檔案頭标志查找,找到後移動及重命名。
幸運的是所有的重要資料100%都被我們找到了。樹的不直覺性加上程式的調試,使得整個恢複工作異常繁雜,在繁亂的資訊樹中跟來跟去,真是煩人得很,幸好撐下來了。繁鎖的資料恢複分析工作真不是人幹的。
。。。
應該讓機器幹 ^_^
本文轉自 宋國建 51CTO部落格,原文連結:http://blog.51cto.com/sun510/1913864,如需轉載請自行聯系原作者