【虛擬機器資料恢復】誤刪除VMware虛擬機器vmdk檔案的資料恢復案例

北亞資料恢復發表於2022-06-17

虛擬機器資料恢復環境:

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虛擬磁碟已經全部清零了(在建立虛擬磁碟的時候會選擇創

建磁碟的型別),也就是說這個新建的虛擬機器所佔用的磁碟空間全部被清零。 如果新虛擬磁碟佔用了刪除虛擬機器磁碟所釋放

的空間,那麼此部分空間將無法恢復的。

圖一:(故障虛擬機器的目錄項區域)


3、虛擬機器資料恢復實施方案一:

a、底層分析。根據VMFS卷的結構以及刪除虛擬磁碟的檔案系統資訊,在底層的自由空間中掃描符合刪除虛擬機器磁碟的區域

,並統計其數量和大小是否符合刪除虛擬磁碟的大小。

b、根據虛擬磁碟中的檔案系統的資訊將掃描到的碎片進行排列組合,結果發現中間有好多碎片缺失,再對這些缺失的碎片進

行重新掃描,發現這些碎片確實沒有找到。

c、將掃描到的碎片按照虛擬磁碟原本的順序重組,對於沒有找到的碎片暫且留空。

d、利用虛擬磁碟快照程式將重組好的父盤和快照盤進行合併,生成一個新的虛擬磁碟。

e、用專業工具解釋虛擬磁碟中的檔案系統,因缺失好多資料,檔案系統解釋過程中有很多報錯,提示某些檔案損壞。


圖二(解釋完的檔案系統):



f、在解析完檔案系統後發現沒有找到原始的資料庫檔案,而宏橋備份和索菲備份這兩個目錄的目錄結構正常。但是在嘗試將

備份匯入資料庫中時,資料庫匯入程式提示報錯。


圖三(宏橋備份和索菲備份的部分目錄結構):




匯入.BAK檔案報錯資訊如下:



4、虛擬機器資料恢復實施方案二:

a、由於方案一中沒有將原始的資料庫檔案恢復出來,並且其中好多備份檔案都無法正常使用。因此採用第二套方案來恢復尚

未恢復的資料庫檔案。

b、根據SQL Server資料庫的結構去自由空間中找到資料庫的開始位置。在資料庫的結構中,資料庫的第9個頁會記錄本資料

庫的資料庫名。因此根據這個特徵可以核對此資料庫的頭部頁是否是正在查詢的。並且資料庫的每個頁中都會記錄資料庫頁

編號以及檔案號,所以根據這些特徵編寫資料庫掃描程式,

然後利用程式去底層掃描所有符合資料庫頁的資料碎片。

c、將掃描出來的碎片按順序重組成一個完整MDF檔案,再透過MDF校驗程式檢測整個MDF檔案是否完整。在整個校驗過程

中,只有cl_system3.dbf和erp42_jck.dbf因有部分碎片沒有找到外,其餘資料庫均校驗成功。校驗完的MDF檔案如下:



d、cl_system3.dbf和erp42_jck.dbf因底層有很多碎片沒有找到(初步懷疑可能被覆蓋),因此校驗不透過。如下是

cl_system3.dbf檔案中某個碎片丟失的區域:



5、虛擬機器資料恢復實施方案三:

a、由於上述兩個方案並沒有將所有的資料庫檔案全部恢復出來,還有cl_system3.dbf和erp42_jck.dbf這2個檔案因缺失部

分頁無法正常使用。因此需要採用備份來恢復這兩個資料庫檔案,但是在檢查完這兩個檔案的備份後發現cl_system3.dbf的

3月某一天的資料因備份機制故障沒有備份出來,而erp42_jck.dbf的3月份備份則全部沒有,只有4月份的全部增量備份:



由於erp42_jck.dbf檔案中只缺失少量的頁,因此可以根據缺失的頁號在增量備份中查詢,再將找到的頁補到erp42_jck.dbf文

件中,這樣可以恢復一部分丟失的資料庫頁。補完後還是缺失部分頁,無法正常使用。但是透過北亞自主開發的資料庫解析程

序將erp42_jck.dbf檔案中比較重要的幾十張表成功匯出,併成功匯入到新建的資料庫中。


驗證資料:

在本地伺服器中搭建和原始環境一樣的資料庫環境(SQL Server 2008),由管理員透過Teamviewer遠端工具連線到驗證服

務器,並安裝上層宏橋應用軟體。驗證資料庫基本沒有發現問題,上層應用可以正常執行,資料記錄也都基本沒有缺失,數

據庫成功掛載。本次資料恢復完成。



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

相關文章