340
Xen Server虛擬機刪除數據的恢複過程
故障描述
1、硬件架構概述
服務器：Dell 720服務器配戴一張H710P的RAID卡。
存儲陣列：由4塊希捷2T STAT硬盤組成的RAID 10。
操作係統：Xen Server 6.2版本。
2、故障虛擬機概述
操作係統：Windows Server 2003。
應用：Web服務器（ASP + SQL 2005的網站架構）。
虛擬磁盤：10G係統盤 + 5G數據盤。
故障描述：因特殊原因導致Xen Server服務器中一台VPS（即Xen Server虛擬機）不可用，虛擬磁盤中數據丟失。
故障分析
1、備份數據；先將客戶的數據盤連接到恢複環境服務器上，然後準備比客戶數據總容量還要大的空間。將客戶數據盤以磁盤底層扇區的方式鏡像到準備的空間上，以確保客戶的數據安全。
2、分析故障原因；仔細分析底層數據發現Xen Server服務器中虛擬機的磁盤都是以LVM的結構存放的，即每個虛擬機的虛擬磁盤都是一個LV，並且虛擬磁盤的模式是精簡模式的。LVM的相關信息在Xen Server中都有記載，查看“/etc/lvm/backup/ “下LVM的相關信息發現並沒有存在損壞的虛擬磁盤信息，因此可以斷定LVM的信息已經被更新了。接著分析底層看能否找到未被更新的LVM信息，果不其然在底層發現了還未更新的LVM信息。如下圖：
圖一： 
根據未被更新的LVM信息找到了虛擬磁盤的數據區域，發現該區域的數據已被破壞。分析後發現造成虛擬機不可用的最終原因是因為虛擬機的虛擬磁盤被破壞，從而導致虛擬機中的操作係統和數據丟失。而導致這種情況的發生很有可能是虛擬機遭遇網絡攻擊或hack入侵後留下惡意程序造成的。仔細核對這片區域後發現，雖然該區域有很多數據被破壞了，但還是發現了很多數據庫的頁碎片。因此可以嚐試將許多數據庫的頁碎片拚成一個可用的數據庫。
解決方案
1、方案一：恢複數據庫備份；根據客戶描述，數據庫在4月份做過一次備份，並將這個數據庫備份文件和網站代碼一起壓縮到一個RAR的壓縮包中。因此隻需要恢複這個壓縮包即可恢複這個備份的數據庫和網站的源代碼。
2、方案二：拚數據庫碎片；由於數據區被破壞，因此隻能在底層根據數據庫的結構將將數據庫的碎片按照原有的順序都拚接起來，然後做數據庫的修複以及數據庫的校驗即可恢複此數據庫。
恢複數據
1、實施方案一；按照方案一的思路進行底層分析，根據RAR壓縮包的結構可以找到很多壓縮包的數據開始位置，而RAR壓縮包文件的第一個扇區中會記錄此RAR的文件名。因此根據從客戶那裏得知備份數據庫的壓縮包文件名和目前找到的壓縮包位置的文件名相匹配，即可找到備份數據庫壓縮包的開始位置。找到壓縮包的位置後仔細分析這片區域的數據，然後將此區域的數據恢複出來重命名為一個RAR格式的壓縮文件。然後嚐試解壓此壓縮包，發現解壓報錯。
圖二：
仔細分析恢複出來的壓縮包發現中有部分數據被破壞了，因此解壓的時候報錯。嚐試使用RAR的修複工具看能否忽略錯誤，解壓部分數據。結果修複完成之後解壓的數據庫隻有網站的部分代碼，並沒有數據庫的備份文件。因此可以判斷數據的備份文件在RAR壓縮包中是損壞的。
圖三：如下是解壓出來的部分網站代碼。
2、實施方案二：由於方案一並沒有將數據庫恢複出來，因此采用方案二來恢複數據。根據SQL Server數據庫的結構去底層分析數據庫的開始位置，在數據庫的結構中，第9個頁會記錄本數據庫的數據庫名。因此在客戶那裏獲取數據庫的名稱之後，再分析底層找到此數據庫的開始位置。因為在數據庫的每個頁中都會記錄數據庫頁編號以及文件號，所以可以根據這些特征編寫程序去底層掃描符合數據庫頁的數據。
然後將掃描出來的碎片按順序重組成一個完整MDF文件，再通過MDF校驗程序檢測整個MDF文件是否完整。重建的MDF文件如下：
圖四：
3、搭建環境驗證數據
檢測沒問題之後再由我們的數據庫工程師搭建數據庫環境，將重組後的數據庫附加到搭建好的數據庫環境中。然後查詢相關表數據是否正常，查詢最新數據是否存在。截圖如下：
圖五： 
驗證數據
由於數據庫需要結合網站代碼才能更好的驗證數據庫的完整性，而網站源代碼大部分都被破壞了，備份中的源代碼也隻有部分才可以用。客戶從開發商裏拿到了網站代碼搭建好了環境，然後將恢複好的數據庫發給用戶。經用戶驗證後，數據庫沒問題。
恢複總結
由於客戶數據被非法破壞，因此恢複難度很大。底層大量的數據都被破壞了，但是客戶重要的是SQL Server數據庫，因此隻需要恢複數據庫文件即可。因此通過拚數據庫碎片的方式成功將數據庫恢複完成，整個數據恢複成功。
最後更新：2017-04-01 16:39:46