瞭解這些資訊，你會知道在ESXi5.0 的虛擬化系統下檔案出現故障時，我們能做些什麼？

【ESXi 5 虛擬化 系統 情景概述 】

使用者使用的儲存模式是透過 iSCSI 方式 來實現 FC SAN 的功能。 同時利用 DELL 伺服器做的物理儲存架構，利用 FreeNAS 來 實現 iSCSI 。並另外透過 兩臺 DELL 伺服器做 ESXi5.0 的虛擬化系統。

1、 FreeNAS 層為 UFS2 檔案系統，整個儲存建一個稀疏模式的檔案， 掛載在 ESXi5.0 系統 上 。

2、 ESXi 系統內 執行 6 臺虛擬機器，其中有三臺最為重要。

3、 第一臺 windows2003 系統虛擬機器是此公司在當地的入口網站 。

混合構架型別： ASP.net 和 PHP

資料庫 型別：  SqlServer2005 和 M ysql 5.1 。

4、 第二臺 FreeBSD 系統， 執行 Mysql 資料庫，供其它多臺虛擬機器使用。

5、 第三臺 windows2003 伺服器，儲存新開發的程式程式碼。

【ESXi 5 虛擬化 系統故障 描述 】

工作人員在檢查時發現 ESXi 系統 無法連線 儲存， 透過後續的排查 在FreeNAS 中發現 UFS2 檔案系統出現 故障 ， 之後用 fsck 對檔案系統進行修復 。 修復後 ESXi 系統可以連上儲存，但 ESXi 系統未能識別到原來的資料儲存和 VMFS 檔案系統， 工作人員 格式化VMFS 後發現 沒有任何資料 。

【 ESXi 5 虛擬化 系統 資料恢復步驟 】

1 、 FreeNAS 檔案系統 --- 應用構架層次：

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

2 、 FreeNAS 檔案系統 -- 分析儲存：

映象 FreeNAS 層，分析儲存， 我們可以 發現一個900 多 GB 的大檔案，檔名： iscsidata 1 。透過UFS2 檔案系統的二進位制結構，定位到 iscsidata 1   檔案的Inode 資料，發現此檔案 有被重建的跡象 ，inode 指標指向的資料量很少。 FreeNAS 層無法解決，就無法進入到的 VMFS 層分析 階段 。

收集UFS2 檔案系統的重要結構：

塊大小：16KB

Segment 大小： 2KB

柱面組大小：188176 KB

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

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

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

3 、 FreeNAS 檔案系統 -- 開始分析 VMFS 層：

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

【ESXi 5 虛擬化 系統恢復結果】

經使用者驗收，資料無誤，至此資料恢復工作結束。