伺服器資料恢復案例:FreeNAS資料恢復過程記錄

北亞資料恢復發表於2019-09-09

【伺服器資料恢復背景】

本次資料恢復的裝置是一臺伺服器,使用的是FreeNAS做iSCSI,再借助於兩臺伺服器做虛擬化系統。FreeNAS層面是UFS2檔案系統,整個伺服器建一個檔案然後掛在給ESXi5.0 系統。這個虛擬化系統中一共有5臺虛擬機器,其中一臺虛擬機器採用了ASP.net和 PHP 混合構架,SqlServer2005和 mysql 5.1兩個資料庫。還有另一臺是FreeBSD系統,MySQL資料庫,還有一臺伺服器儲存的是程式碼資料,這三臺虛擬機器是該伺服器上資料恢復的重點資料,必須要進行完美資料恢復。

【伺服器資料恢復故障】

需要資料恢復的伺服器在正常執行過程中意外斷電,重啟後虛擬化系統無法連結伺服器,FreeNAS中發現UFS2檔案系統出現問題,該公司管理員對檔案系統進行了修復,但是ESXI系統不能識別原有資料和檔案系統。管理員聯絡到資料恢復中心進行伺服器資料恢復。

【伺服器資料恢復過程】

分析故障,最大化利用可用資訊。開始抽絲剝繭:

應用構架層次:FreeNAS(UFS2檔案系統–> 一個大的稀疏模式的檔案) –> ESXi 5.0(VMFS檔案系統層) -> 單臺虛擬機器的虛擬磁碟 (windows-NTFS檔案系統/FreeBSD-UFS2檔案系統)。

第一步是映象 FreeNAS 層,然後分析整個儲存,發現就一個900多GB的大檔案,檔名: iscsidata。透過UFS2檔案系統的二進位制結構,定位到 iscsidata 檔案的Inode資料,發現此檔案被重建過,inode指標指向的資料量很少。FreeNAS層無法解決,就無法進入到下一步的 VMFS層分析。

收集UFS2檔案系統的重要結構:
塊大小:16KB
Segment 大小:2KB
柱面組大小:188176 KB

UFS2一個資料指標佔 8位元組,一個塊可儲存 2048個資料指標。那麼一個二級指標塊則可儲存:2048*2048*16KB= 64GB 資料。一個三級指標塊則可儲存 64GB*2048= 128TB 資料。如果能找到 iscsidata 檔案的三級指標塊就能解決 FreeNAS層問題。但iscsidata檔案重建過,過程和大小都和原始的一樣,估計有部分指標塊已被覆蓋。原始 iscsidata 檔案的 inode和新建的 iscsidata 檔案的 inode 就在一個位置,嘗試進行搜尋,無其它有用的inode出現。只得現場寫程式收集有用的指標塊:

圖一:(圖片來源於資料恢復中心)

由於iscsidata檔案是使用稀疏模式,收集條件只能放寬,收集到了大量三級指標塊和二級指標塊。對收集到的所有三級指標塊進行分析,都是無效的,無iscsidata檔案使用的三級指標塊,估計在新建iscsidata檔案時被新的覆蓋(新的iscsidata檔案在掛載到ESXi5.0後有個VMFS格式化過程,而 ESXi5.0 使用GPT分割槽,GPT分割槽會在磁碟最後寫入冗餘的GPT頭和分割槽表資訊資料,這樣會使用iscsidata檔案的三級指標塊)。

現只能分析收集到的二級指標塊,對有大量的二級指標塊的指向資料進行DUMP,然後再從磁碟中的資料定位到二級指標。這樣得到大量DUMP的資料。

開始分析 VMFS 層:

重格式化過VMFS,和原始UFS2的指標已丟失,造成VMFS元檔案已基本上不可用,無重要的參考資訊,所幸虛擬機器都無快照,仍可恢復。透過單臺虛擬機器層(windows(NTFS)和 FreeBSD(UFS2)系統的檔案系統結構),向上定位到VMFS層,在透過VMFS層定位到DUMP出的單個64GB 檔案,透過多次組合,最終這三臺重要的虛擬機器的虛擬磁碟都已完全恢復。將恢復出的網頁資料和資料庫資料上傳到一新構建的系統中,拉起應用,資料完全無問題。

圖二:(圖片來源於資料恢復中心)

【伺服器資料恢復結果】

耗時3天,該伺服器內的所有資料成功恢復。

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

相關文章