備份數據

　　在VMware vSphere Client上將掛載的RD220i存儲中VMFS卷以正常方式卸載掉。然后將RD220i存儲上的VMFS卷通過網線的方式連接到備份服務器上，接著使用專業的工具將整個VMFS卷以扇區的方式鏡像到已準備的備份空間上，以確?？蛻舻?a href="/tag/25376" target="blank">數據安全，之后的分析和恢復操作均在備份的數據上進行。

　　分析故障原因

　　仔細分析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卷的結構以及刪除虛擬磁盤的文件系統信息，在底層的自由空間中掃描符合刪除虛擬機磁盤的區域，并統計其數量和大小是否符合刪除虛擬磁盤的大小。再根據虛擬磁盤中的文件系統的信息將這些掃描到的碎片進行排列組合，結果發現中間有好多碎片缺失，仔細再對這些缺失的碎片進行重新掃描，發現這些碎片確實沒有找到。接著將掃描到的碎片安照虛擬磁盤原本的順序重組，對于沒有找到的碎片暫且留空。接下來利用虛擬磁盤快照程序將重組好的父盤和快照盤進行合并，生成一個新的虛擬磁盤。再用專業工具解釋虛擬磁盤中的文件系統，因缺失好多數據，文件系統解釋過程中報好多錯誤，提示某些文件損壞。

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

　　方向二實施過程

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

　　cl_system3.dbf和erp42_jck.dbf因底層有很多碎片沒有找不到(初步懷疑可能被覆蓋)，因此校驗不通過。

　　方向三實施過程

　　由于上述兩個方向實施完后，并沒有將所有的數據庫文件全部恢復出來，還有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數據庫底層結構足夠了解，并且有處理過類似故障類型的經驗。所以整個恢復過程中還算比較順利。數據庫均正?；謴停⑶因炞C沒有問題，整個數據恢復成功。