IBM X3850伺服器誤刪虛擬機器後如何恢復資料

一、伺服器故障描述
1、架構環境概述
伺服器：IBM X 3850系列伺服器（用於VMware虛擬主機）。
儲存陣列：柏科RD220i系列儲存（用於存放虛擬機器檔案）。
作業系統：VMware ESXi 5.5版本。
2、故障虛擬機器概述
作業系統：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虛擬磁碟已經全部清零了（在建立虛擬磁碟的時候會選擇建立磁碟的型別），也是這個新建的虛擬機器所佔用的磁碟空間全部被清零。 如果新虛擬磁碟佔用了刪除虛擬機器磁碟所釋放的空間，那麼此部分空間將無法恢復的。
如下圖：（是故障虛擬機器的目錄項區域）
圖一：

    
三、實施方向
1、實施方向一：恢復刪除的VMDK檔案
    根據刪除虛擬磁碟檔案中的檔案系統以及虛擬磁碟中的檔案型別在VMFS卷的自由空間中進行碎片匹配和合並，最終恢復刪除的虛擬磁碟檔案，再利用快照合併程式將快照檔案和恢復的虛擬磁碟檔案合併成一個完整的虛擬磁碟檔案，然後利用專業的檔案系統解釋工具解釋虛擬磁碟檔案中的所有檔案。
2、實施方向二：恢復MSSQL資料庫檔案
    如果方向一實施的效果不太理想，接下來可根據SQL Server資料庫檔案的結構，對VMFS卷自由空間中符合SQL Server頁結構的資料區域進行統計、分析和聚合，最終生成一個可以正常使用的.MDF格式的檔案。
3、實施方向三：恢復MSSQL資料庫備份檔案
    由於資料庫每天都在做備份，雖然每天一次增量備份，15天一次全部備份。但是如果上述兩種方案實施過後還有一些資料庫無法恢復的話，則只能利用恢復備份檔案來恢復資料庫了。根據掌握的備份檔案.bak的結構，對VMFS卷自由空間中符合SQL Server備份檔案結構的資料區域進行統計、分析和聚合，最終生成一個可以正常匯入到SQL Server資料庫中.BAK格式的檔案。

四、恢復資料
1、方向一實施過程
    按照方向一的思路進行底層分析，根據VMFS卷的結構以及刪除虛擬磁碟的檔案系統資訊，在底層的自由空間中掃描符合刪除虛擬機器磁碟的區域，並統計其數量和大小是否符合刪除虛擬磁碟的大小。再根據虛擬磁碟中的檔案系統的資訊將這些掃描到的碎片進行排列組合，結果發現中間有好多碎片缺失，仔細再對這些缺失的碎片進行重新掃描，發現這些碎片確實沒有找到。接著將掃描到的碎片安照虛擬磁碟原本的順序重組，對於沒有找到的碎片暫且留空。接下來利用虛擬磁碟快照程式將重組好的父盤和快照盤進行合併，生成一個新的虛擬磁碟。再用專業工具解釋虛擬磁碟中的檔案系統，因缺失好多資料，檔案系統解釋過程中報好多錯誤，提示某些檔案損壞。
圖二：

    
在解析完檔案系統後發現沒有找到原始的資料庫檔案，而宏橋備份和索菲備份這兩個目錄的目錄結構正常。但是在嘗試將備份匯入資料庫中時，資料庫匯入程式提示報錯。

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


2、方向二實施過程
    由於方向一中並沒有將原始的資料庫檔案恢復出來，並且其中好多備份檔案都無法正常使用。因此需採用第二套方案來恢復尚未恢復的資料庫檔案。根據SQL Server資料庫的結構去自由空間中找到資料庫的開始位置。在資料庫的結構中，資料庫的第9個頁會記錄本資料庫的資料庫名。因此根據這個特徵可以核對此資料庫的頭部頁是否是正在查詢的。並且資料庫的每個頁中都會記錄資料庫頁編號以及檔案號，所以根據這些特徵編寫資料庫掃描程式，然後利用程式去底層掃描所有符合資料庫頁的資料碎片。接著將掃描出來的碎片按順序重組成一個完整MDF檔案，再透過MDF校驗程式檢測整個MDF檔案是否完整。在整個校驗過程中，只有cl_system3.dbf和erp42_jck.dbf因有部分碎片沒有找到外，其餘資料庫均校驗成功。
圖六：


cl_system3.dbf和erp42_jck.dbf因底層有很多碎片沒有找不到（初步懷疑可能被覆蓋），因此校驗不透過。如下是cl_system3.dbf檔案中某個碎片丟失的區域：
圖七：


3、方向三實施過程
由於上述兩個方向實施完後，並沒有將所有的資料庫檔案全部恢復出來，還有cl_system3.dbf和erp42_jck.dbf這裡個檔案因缺失部分頁導致其無法正常使用。因此需要採用備份來恢復這兩個資料庫檔案，但是在檢查完這兩個檔案的備份後發現cl_system3.dbf的3月30號全部備份因備份機制故障導致沒有備份出來，而erp42_jck.dbf的3月份備份全部沒有，只有4月份的全部增量備份，
圖八：


由於erp42_jck.dbf檔案中只缺失少量的頁，因此可以根據缺失的頁號在增量備份中查詢，再將找到的頁補到erp42_jck.dbf檔案中，這樣可以恢復一部分丟失的資料庫頁。最終補完後還是缺失部分頁，無法正常使用。但是可以透過自主開發的資料庫解析程式將erp42_jck.dbf檔案中使用者比較重要的幾十張表成功匯出，併成功匯入到新建的資料庫中。

五、驗證資料
    在本地伺服器中搭建和原始環境一樣的資料庫環境（SQL Server 2008），由客戶透過Teamviewer遠端工具連線到驗證伺服器，並安裝上層宏橋應用軟體。再由客戶安排工程驗證資料庫是否完整，經過仔細的驗證後，資料庫恢復基本沒問題。上層應用可以正常執行，資料記錄也都基本沒有缺失，資料恢復成功。
資料庫成功掛載，
圖九：


六、恢復總結
    由於客戶資料先是被突然斷電導致其部分檔案丟失，接著人為刪掉了部分資料，並且又重新寫入部分資料，導致其存在資料覆蓋的可能性。最後又因資料庫的備份機制原因導致部分資料庫的備份資料沒有，因此整個恢復難度很大。由於對SQL Server資料庫底層結構足夠了解，並且有處理過類似故障型別的經驗。所以整個恢復過程中還算比較順利。資料庫均正常恢復，並且驗證沒有問題，整個資料恢復成功。