Dell R710系列伺服器（用于VMware虛拟主機），Dell MD 3200系列存儲（用于存放虛拟機檔案），VMware ESXi 5.5版本，因意外斷電，導緻某台虛拟機不能正常啟動，檢視虛拟機的配置檔案時發現此虛拟機的配置檔案除了磁盤檔案以外其他配置檔案全部丢失。此時xxx-flat.vmdk磁盤檔案和xxx-000001-delta.vmdk快照檔案還存在。找VMware工程師診斷後，嘗試建立一個虛拟機來解決故障，但發現ESXi存儲空間不足。是以就将故障虛拟機下的xxx-flat.vmdk磁盤檔案删除了，這時ESXi存儲就有200多G的剩餘空間了，而後VMware工程師就重建立了一個40G的虛拟機，并且配置設定了固定大小的虛拟磁盤，Windows Server 2008（虛拟機作業系統），資料庫應用環境SQL Server 2008資料庫伺服器（管理宏橋和索菲兩套應用資料庫），虛拟機磁盤容量200G資料盤（精簡模式）+ 160G快照資料盤。
在VMware vSphere Client上将挂載的RD220i存儲中VMFS卷以正常方式解除安裝掉。然後将RD220i存儲上的VMFS卷通過網線的方式連接配接到備份伺服器上，接着使用專業的工具将整個VMFS卷以扇區的方式鏡像到已準備的備份空間上，以確定客戶的資料安全，之後的分析和恢複操作均在備份的資料上進行。
2、分析故障原因
仔細分析VMFS卷的底層資料發現，ESXi主機的突然斷電導緻故障虛拟機目錄下的目錄項出現破壞，但是這種破壞不會影響虛拟機的重要資料，隻是破壞了檔案的目錄項而已，可以通過人工修複即可解決。而人為删除某個檔案的話，則目錄項對應的資料區索引會被清掉，也不會影響删除檔案的實際資料。這種情況可根據删除虛拟磁盤檔案中的檔案系統以及虛拟磁盤中的檔案類型在VMFS卷自由空間中進行碎片比對和合并，最終也可恢複删除的虛拟磁盤檔案。但是在上述的兩種情況之下又建立了一台虛拟機，并且配置設定了虛拟磁盤。經過仔細分析發現配置設定的40G虛拟磁盤已經全部清零了（在建立虛拟磁盤的時候會選擇建立磁盤的類型），也是這個建立的虛拟機所占用的磁盤空間全部被清零。如果新虛拟磁盤占用了删除虛拟機磁盤所釋放的空間，那麼此部分空間将無法恢複的。
如下圖：（是故障虛拟機的目錄項區域）
根據删除虛拟磁盤檔案中的檔案系統以及虛拟磁盤中的檔案類型在VMFS卷的自由空間中進行碎片比對和合并，最終恢複删除的虛拟磁盤檔案，再利用快照合并程式将快照檔案和恢複的虛拟磁盤檔案合并成一個完整的虛拟磁盤檔案，然後利用專業的檔案系統解釋工具解釋虛拟磁盤檔案中的所有檔案。
如果方向一實施的效果不太理想，接下來可根據SQL Server資料庫檔案的結構，對VMFS卷自由空間中符合SQL Server頁結構的資料區域進行統計、分析和聚合，最終生成一個可以正常使用的.MDF格式的檔案。
由于資料庫每天都在做備份，雖然每天一次增量備份，15天一次全部備份。但是如果上述兩種方案實施過後還有一些資料庫無法恢複的話，則隻能利用恢複備份檔案來恢複資料庫了。根據掌握的備份檔案.bak的結構，對VMFS卷自由空間中符合SQL Server備份檔案結構的資料區域進行統計、分析和聚合，最終生成一個可以正常導入到SQL Server資料庫中.BAK格式的檔案。
按照方向一的思路進行底層分析，根據VMFS卷的結構以及删除虛拟磁盤的檔案系統資訊，在底層的自由空間中掃描符合删除虛拟機磁盤的區域，并統計其數量和大小是否符合删除虛拟磁盤的大小。再根據虛拟磁盤中的檔案系統的資訊将這些掃描到的碎片進行排列組合，結果發現中間有好多碎片缺失，仔細再對這些缺失的碎片進行重新掃描，發現這些碎片确實沒有找到。接着将掃描到的碎片安照虛拟磁盤原本的順序重組，對于沒有找到的碎片暫且留白。接下來利用虛拟磁盤快照程式将重組好的父盤和快照盤進行合并，生成一個新的虛拟磁盤。再用專業工具解釋虛拟磁盤中的檔案系統，因缺失好多資料，檔案系統解釋過程中報好多錯誤，提示某些檔案損壞。
解釋完的檔案系統如下圖：
在解析完檔案系統後發現沒有找到原始的資料庫檔案，而宏橋備份和索菲備份這兩個目錄的目錄結構正常。但是在嘗試将備份導入資料庫中時，資料庫導入程式提示報錯。
宏橋備份和索菲備份的部分目錄結構如下圖：
<a href="http://s1.51cto.com/wyfs02/M02/8C/68/wKiom1hrXkPTjYoGAABj_HNcsVs435.png-wh_500x0-wm_3-wmp_4-s_1542050362.png" target="_blank"></a>
<a href="http://s2.51cto.com/wyfs02/M02/8C/65/wKioL1hrXkTh6HiFAAEuOKypkM4447.png-wh_500x0-wm_3-wmp_4-s_3115383340.png" target="_blank"></a>
導入.BAK檔案報錯資訊如下:
<a href="http://s3.51cto.com/wyfs02/M01/8C/65/wKioL1hrXn3SeWRuAAH9h9mQ2hM281.jpg" target="_blank"></a>
由于方向一中并沒有将原始的資料庫檔案恢複出來，并且其中好多備份檔案都無法正常使用。是以需采用第二套方案來恢複尚未恢複的資料庫檔案。根據SQL Server資料庫的結構去自由空間中找到資料庫的開始位置。在資料庫的結構中，資料庫的第9個頁會記錄本資料庫的資料庫名。是以根據這個特征可以核對此資料庫的頭部頁是否是正在查找的。并且資料庫的每個頁中都會記錄資料庫頁編号以及檔案号，是以根據這些特征編寫資料庫掃描程式，然後利用程式去底層掃描所有符合資料庫頁的資料碎片。接着将掃描出來的碎片按順序重組成一個完整MDF檔案，再通過MDF校驗程式檢測整個MDF檔案是否完整。在整個校驗過程中，隻有cl_system3.dbf和erp42_jck.dbf因有部分碎片沒有找到外，其餘資料庫均校驗成功。校驗完的MDF檔案如下：
<a href="http://s1.51cto.com/wyfs02/M02/8C/68/wKiom1hrXpnxXOi7AAJr9XuTBhQ151.jpg" target="_blank"></a>
cl_system3.dbf和erp42_jck.dbf因底層有很多碎片沒有找不到（初步懷疑可能被覆寫），是以校驗不通過。如下是cl_system3.dbf檔案中某個碎片丢失的區域：
<a href="http://s1.51cto.com/wyfs02/M00/8C/68/wKiom1hrXrPxrKZNAAOMgnzfC4o028.jpg" target="_blank"></a>
由于上述兩個方向實施完後，并沒有将所有的資料庫檔案全部恢複出來，還有cl_system3.dbf和erp42_jck.dbf這裡個檔案因缺失部分頁導緻其無法正常使用。是以需要采用備份來恢複這兩個資料庫檔案，但是在檢查完這兩個檔案的備份後發現cl_system3.dbf的3月30号全部備份因備份機制故障導緻沒有備份出來，而erp42_jck.dbf的3月份備份全部沒有，隻有4月份的全部增量備份，如下圖：
<a href="http://s4.51cto.com/wyfs02/M00/8C/65/wKioL1hrXt-T82xvAATeEPkbPSg149.jpg" target="_blank"></a>
由于erp42_jck.dbf檔案中隻缺失少量的頁，是以可以根據缺失的頁号在增量備份中查找，再将找到的頁補到erp42_jck.dbf檔案中，這樣可以恢複一部分丢失的資料庫頁。最終補完後還是缺失部分頁，無法正常使用。但是可以通過自主開發的資料庫解析程式将erp42_jck.dbf檔案中使用者比較重要的幾十張表成功導出，并成功導入到建立的資料庫中。
在本地伺服器中搭建和原始環境一樣的資料庫環境（SQL Server 2008），由客戶通過Teamviewer遠端工具連接配接到驗證伺服器，并安裝上層宏橋應用軟體。再由客戶安排工程驗證資料庫是否完整，經過仔細的驗證後，資料庫恢複基本沒問題。上層應用可以正常運作，資料記錄也都基本沒有缺失，資料恢複成功。
資料庫成功挂載，如下圖：
<a href="http://s3.51cto.com/wyfs02/M00/8C/68/wKiom1hrXwXgn8yjAASZiv4lpPo287.jpg" target="_blank"></a>
由于對SQL Server資料庫底層結構足夠了解，并且有處理過類似故障類型的經驗。是以整個恢複過程中還算比較順利。資料庫均正常恢複，并且驗證沒有問題，整個資料恢複成功。
本文轉自 張宇 51CTO部落格，原文連結：http://blog.51cto.com/zhangyu/1888657，如需轉載請自行聯系原作者
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)