虛擬機數據恢復案例介紹：本次數據恢復案例中共涉及一臺R710系列服務器和一臺MD3200系列存儲，上層是虛擬機和虛擬文件，虛擬機系統版本爲ESXI5.5版本，由於客戶的機房非正常斷電導致虛擬機不能啓動。機房管理員對虛擬機進行了檢查，虛擬機配置文件丟失，繼續查詢發現了xxx-flat.vmdk磁盤文件和xxx-000001-delta.vmdk快照文件還存在。管理員在試圖恢復虛擬機的時候將原虛擬機內的xxx-flat.vmdk刪除然後新建了一個虛擬機，分配了200GB的精簡模式和160GB的快照數據盤，但是原虛擬機內的數據並沒有恢復。
下面介根據數據恢復工程師的數據恢復步驟介紹虛擬機的數據恢復方法：數據恢復第一步先將掛載在VMware vSphere Client上的捲進行卸載，然後進行備份，方便數據恢復工程師進行數據檢測和數據恢復。
經過數據恢復工程師對備份數據進行檢測和分析發現虛擬機目錄項由於非正常斷電被破壞掉了，管理員刪除的文件導致了文件的數據區索引被清除，重建虛擬機導致分配給新建虛擬機的磁盤數據被底層清零。前兩者可以通過人工修復進行恢復數據，但新建虛擬機的操作直接導致了底層數據的清零，如果新建虛擬機磁盤的空間佔用了原有虛擬機的釋放空間則會導致這部分數據無法恢復，具體需要進一步檢測。下圖爲虛擬機的目錄項：
圖一：虛擬機數據恢復案例之虛擬機目錄項
虛擬化數據恢復工程師對底層數據進行分析，在自由空間內排查被刪除的虛擬機磁盤區域，對這部分區域進行掃描發現了大量的碎片，隨後對碎片進行重組，但是經過拼接和重組後發現仍然缺失部分碎片文件，只能暫時將丟失的文件碎片位置留空。接下來利用虛擬磁盤快照程序將重組好的父盤和快照盤進行合併，生成一個新的虛擬磁盤。再用專業工具解釋虛擬磁盤中的文件系統，因缺失好多數據，文件系統解釋過程中報好多錯誤，提示某些文件損壞。解釋完的文件系統如下圖：
圖二：虛擬機數據恢復案例之文件系統解釋結果
在解析完文件系統後發現沒有找到原始的數據庫文件，而宏橋備份和索菲備份這兩個目錄的目錄結構正常。但是在嘗試將備份導入數據庫中時，數據庫導入程序提示報錯。宏橋備份和索菲備份的部分目錄結構如下圖：
圖三：虛擬機數據恢復案例之目錄結構
導入.BAK文件報錯信息如下:
圖四：虛擬機數據恢復案例之：文件報錯信息
虛擬機數據恢復工程師根據SQL Server數據庫的結構去自由空間中找到數據庫的開始位置。數據庫的庫名通常反應在當前庫的第九頁內，根據這一特性可以藉助一些數據恢復工具到底層掃描數據庫頁的碎片，然後使用數據庫水片重組mdf文件，在本次數據恢復案例中除了cl_system3.dbf和erp42_jck.dbf因有部分碎片沒有找到外（極有可能這部分數據被覆蓋了），其餘數據庫均校驗成功。校驗完的MDF文件如下：
圖五：虛擬機數據恢復案例之數據庫校驗成功
cl_system3.dbf文件中某個碎片丟失的區域如下圖：
圖六：虛擬機數據恢復案例之碎片丟失區域
虛擬機數據恢復工作進行到這一步已經將可用的數據都用的差不多了，數據依然沒有恢復完全，只剩下最後一個希望，那就是備份文件，數據恢復工程師對備份文件進行了詳細的檢查發現丟失的兩個文件依然不存在，只有部分增量備份文件。
由於erp42_jck.dbf文件中只缺失少量的頁，因此可以根據缺失的頁號在增量備份中查找，再將找到的頁補到erp42_jck.dbf文件中，這樣可以恢復一部分丟失的數據庫頁。最終補完後還是缺失部分頁，無法正常使用。但是可以通過自主開發的數據庫解析程序將erp42_jck.dbf文件中用戶比較重要的幾十張表成功導出，併成功導入到新建的數據庫中，缺失的文件就這樣恢復了。
數據驗證：在數據恢復安全設備中重新搭建原始環境，將恢復出來的數據導入到數據恢復安全環境中，再由客戶親自前往驗證數據庫的完整性，經過驗證所有數據均完整沒有缺失、數據庫掛載成功、上層應用運行正常，本次虛擬機數據恢復成功。