虛拟機數據恢複環境：

Dell PS系列服務器（用于VMware虛拟主機）；

VMware ESXi5.5版本；

虛拟機操作系統：Windows Server 2008；

數據庫：SQL Server 2008數據庫服務器（管理宏橋和索菲兩套應用數據庫）；

虛拟機磁盤：200G數據盤（精簡模式） 160G快照數據盤。

虛拟機故障：

意外斷電導緻某台虛拟機不能正常啟動，配置文件中除了磁盤文件以外其他配置文件全部丢失。此時xxx-flat.vmdk磁盤文件和xxx-000001-delta.vmdk快照文件還在。找VMware工程師診斷後，嘗試新建一個虛拟機來解決故障，但發現ESXi存儲空間不足。因此就将故障虛拟機下的xxx-flat.vmdk磁盤文件删除了，這時ESXi存儲就有200多G的剩餘空間了，VMware工程師重新創建了一個40G的虛拟機，并分配了固定大小的虛拟磁盤。

虛拟機數據恢複過程：

1、備份數據。

在VMware vSphere Client上将挂載的RD220i存儲中VMFS卷以正常方式卸載掉，然後将RD220i存儲上的VMFS卷通過網線的方式連接到備份服務器上，使用工具将整個VMFS卷以扇區的方式鏡像到已準備好的備份空間上，之後的分析和數據恢複操作均在備份的數據上進行。

2、分析故障原因

仔細分析VMFS卷的底層數據，發現ESXi主機的突然斷電導緻故障虛拟機目錄下的目錄項出現破壞，但是這種破壞不會影響虛拟機的重要數據，隻是破壞了文件的目錄項而已，可以通過人工進行修複。而人為删除某個文件的話，則目錄項對應的數據區索引會被清掉，也不會影響删除文件的實際數據。這種情況可根據删除虛拟磁盤文件中的文件系統以及虛拟磁盤中的文件類型在VMFS卷自由空間中進行碎片匹配和合并，最終恢複删除的虛拟磁盤文件。但是在上述的兩種情況之下又新建了一台虛拟機，并且分配了虛拟磁盤。經過仔細分析發現分配的40G虛拟磁盤已經全部清零了（在創建虛拟磁盤的時候會選擇創建磁盤的類型），也就是說這個新建的虛拟機所占用的磁盤空間全部被清零。 如果新虛拟磁盤占用了删除虛拟機磁盤所釋放的空間，那麼此部分空間将無法恢複的。

圖一：（故障虛拟機的目錄項區域）

北亞數據恢複——VMware數據恢複

3、虛拟機數據恢複實施方案一：

a、底層分析。根據VMFS卷的結構以及删除虛拟磁盤的文件系統信息，在底層的自由空間中掃描符合删除虛拟機磁盤的區域，并統計其數量和大小是否符合删除虛拟磁盤的大小。

b、根據虛拟磁盤中的文件系統的信息将掃描到的碎片進行排列組合，結果發現中間有好多碎片缺失，再對這些缺失的碎片進行重新掃描，發現這些碎片确實沒有找到。

c、将掃描到的碎片按照虛拟磁盤原本的順序重組，對于沒有找到的碎片暫且留空。

d、利用虛拟磁盤快照程序将重組好的父盤和快照盤進行合并，生成一個新的虛拟磁盤。

e、用專業工具解釋虛拟磁盤中的文件系統，因缺失好多數據，文件系統解釋過程中有很多報錯，提示某些文件損壞。

圖二（解釋完的文件系統）：

北亞數據恢複——VMware數據恢複

f、在解析完文件系統後發現沒有找到原始的數據庫文件，而宏橋備份和索菲備份這兩個目錄的目錄結構正常。但是在嘗試将備份導入數據庫中時，數據庫導入程序提示報錯。

圖三（宏橋備份和索菲備份的部分目錄結構）：

北亞數據恢複——VMware數據恢複

北亞數據恢複——VMware數據恢複

導入.BAK文件報錯信息如下：

北亞數據恢複——VMware數據恢複

4、虛拟機數據恢複實施方案二：

a、由于方案一中沒有将原始的數據庫文件恢複出來，并且其中好多備份文件都無法正常使用。因此采用第二套方案來恢複尚未恢複的數據庫文件。

b、根據SQL Server數據庫的結構去自由空間中找到數據庫的開始位置。在數據庫的結構中，數據庫的第9個頁會記錄本數據庫的數據庫名。因此根據這個特征可以核對此數據庫的頭部頁是否是正在查找的。并且數據庫的每個頁中都會記錄數據庫頁編号以及文件号，所以根據這些特征編寫數據庫掃描程序，

然後利用程序去底層掃描所有符合數據庫頁的數據碎片。

c、将掃描出來的碎片按順序重組成一個完整MDF文件，再通過MDF校驗程序檢測整個MDF文件是否完整。在整個校驗過程中，隻有cl_system3.dbf和erp42_jck.dbf因有部分碎片沒有找到外，其餘數據庫均校驗成功。校驗完的MDF文件如下：

北亞數據恢複——VMware數據恢複

d、cl_system3.dbf和erp42_jck.dbf因底層有很多碎片沒有找到（初步懷疑可能被覆蓋），因此校驗不通過。如下是cl_system3.dbf文件中某個碎片丢失的區域：

北亞數據恢複——VMware數據恢複

5、虛拟機數據恢複實施方案三：

a、由于上述兩個方案并沒有将所有的數據庫文件全部恢複出來，還有cl_system3.dbf和erp42_jck.dbf這2個文件因缺失部分頁無法正常使用。因此需要采用備份來恢複這兩個數據庫文件，但是在檢查完這兩個文件的備份後發現cl_system3.dbf的3月某一天的數據因備份機制故障沒有備份出來，而erp42_jck.dbf的3月份備份則全部沒有，隻有4月份的全部增量備份：

北亞數據恢複——VMware數據恢複

由于erp42_jck.dbf文件中隻缺失少量的頁，因此可以根據缺失的頁号在增量備份中查找，再将找到的頁補到erp42_jck.dbf文件中，這樣可以恢複一部分丢失的數據庫頁。補完後還是缺失部分頁，無法正常使用。但是通過北亞自主開發的數據庫解析程序将erp42_jck.dbf文件中比較重要的幾十張表成功導出，并成功導入到新建的數據庫中。

驗證數據：

在本地服務器中搭建和原始環境一樣的數據庫環境（SQL Server 2008），由管理員通過Teamviewer遠程工具連接到驗證服務器，并安裝上層宏橋應用軟件。驗證數據庫基本沒有發現問題，上層應用可以正常運行，數據記錄也都基本沒有缺失，數據庫成功挂載。本次數據恢複完成。

北亞數據恢複——VMware數據恢複