服務器存儲故障：

同友存儲中組建的raid5磁盤陣列由于未知原因崩潰且無法啟動，raid5中的虛拟機全部丢失，其中3台虛拟機中的數據尤為重要，管理員聯系北亞數據恢複中心要求對這3台虛拟機進行數據恢複。

服務器存儲數據恢複過程：

1、分析存儲底層結構。

通過與管理員的溝通和對raid的分析，搞清楚了故障存儲的底層結構：多塊物理磁盤組成一個存儲池并劃分多個lun，需要進行數據恢複的為lun1，lun1包含了那3台虛拟機。如下圖所示：

北亞數據恢複——同友存儲raid數據恢複

存儲結構

2、重組raid。

在對陣列進行分析重組時，數據恢複工程師發現原存儲中的raid5缺失2塊硬盤，熱備盤已經啟用。（還原故障發生的過程：第一塊硬盤掉線後系統啟動熱備盤進行替換，第二塊硬盤掉線時raid5處于降級狀态，第三塊硬盤掉線導緻raid陣列崩潰。）這種情況下無法通過校驗直接獲取丢失盤的數據，隻能使用和磁盤同等大小的全0鏡像進行重組（由于依賴空鏡像組成的raid文件系統結構會破壞嚴重，相當于每個條帶都會缺失兩個塊的數據，所以除非特殊情況不建議如此操作）。

北亞數據恢複——同友存儲raid數據恢複

重建raid

3、通過重組出來的raid陣列提取LUN。通過對存儲結構的進一步分析獲取到存儲劃分的MAP塊，對各個LUN的數據塊指針進行解析。北亞數據恢複工程師編寫數據提取程序提取LUN碎片。提取完成後進行碎片拼接，組成完整LUN。

北亞數據恢複——同友存儲raid數據恢複

提取LUN

4、導出LUN内所有的虛拟機并嘗試啟動，由于操作系統被破壞，虛拟機無法啟動。

5、提取虛拟機内文件。由于虛拟機無法啟動，隻能對虛拟機内的文件進行提取，但多數文件破壞嚴重，隻有少數文件可用，隻好繼續制定其他數據恢複方案。

6、通過分析數據庫頁提取數據。本案例中的虛拟機内有mysql數據庫，可以利用數據庫底層存儲的特殊性進行數據頁掃描，提取數據。（由于父盤和快照文件都被損壞，常規合并操作無法完成快照合并，使用北亞自主研發的VMFS快照合并程序進行快照合并。）數據恢複過程截圖如下：

北亞數據恢複——同友存儲raid數據恢複

7、獲取mysql數據頁并分析。根據mysql數據頁特征進行數據頁掃描并導出（innodb引擎可以使用此方案；myisam因為沒有“數據頁”這個概念，所以這個方案不可用），分析系統表獲取各用戶表信息，根據各個表的id進行數據頁分割。

8、提取表結構、提取記錄。因為數據庫使用時間已久，表結構也曾多次變更，加上系統表在存儲損壞後有部分數據丢失，記錄提取過程遇到很大阻力。首先獲取最初版本數據庫各個表的表結構：合并快照前的父盤因為寫入較早，使用第一塊掉線盤進行校驗獲取到這個文件的完整數據，然後提取出其中數據庫各個表的表結構，之後管理員提供了最新版的數據庫建表腳本。分别使用兩組不同的表結構對數據記錄進行提取并導入恢複環境中的mysql數據庫内，然後剔除各個表中因為表結構變更造成的亂碼數據，最後将兩組數據分别導出為.sql文件。

9、數據驗證。因為兩個版本的數據庫表結構不同，所以管理員聯系應用工程師進行調試。調試完成後導入平台，平台調試成功，本次數據恢複完成。