一、分析存儲底層次結構，制定數據恢復方案。

通過與客戶的溝通及對raid陣列的分析得出故障存儲的底層結構為若幹物理磁盤組成一個存儲池，劃分了多個lun，需要進行數據恢復的為lun1，其中包含重點恢復的3臺虛擬機。如下圖所示：

二、嘗試重組raid恢復raid陣列數據。

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

三、通過重組的raid陣列提取LUN。

通過對存儲結構的進一步分析我們可以獲取到存儲劃分的MAP塊，進而對各個LUN的數據塊指針進行解析，通過編寫數據提取程序（也可借助北亞數據恢復工具）提取LUN碎片。提取完成後進行碎片拼接，組成完整LUN。

四、導出LUN內所有虛擬機，嘗試啟動。

因虛擬機名稱涉及客戶隱私且導出過程較為簡單，此處不再贅述。導出虛擬機後嘗試啟動，同預想相同，操作系統被破壞虛擬機無法啟動。

五、提取虛擬機內文件。

由於虛擬機無法啟動，只能對虛擬機內的文件進行提取，但多數文件破壞嚴重，只有少數文件可用，只好繼續制定其他數據恢復方案。

六、通過分析數據庫頁提取數據。

本次數據恢復的虛擬機內有mysql數據庫，可以利用數據庫底層存儲的特殊性進行數據頁掃描，提取數據。（註，虛擬機啟用快照，父盤和快照文件都被損壞的情況下常規合並操作無法完成，使用本公司自主研發VMFS快照合並程序進行快照合並。）數據恢復過程截圖如下

七、獲取mysql數據頁並分析。

根據mysql數據頁特征進行數據頁掃描並導出（innodb引擎可以使用此方案，myisam因為沒有“數據頁”概念所以不可用），分析系統表獲取各用戶表信息，根據各個表的id進行數據頁分割。因為表內容涉及用戶隱私，此處未配圖

八、提取表結構、提取記錄。

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

九、數據驗證，raid數據恢復成功。

因為兩個版本的數據庫表結構不同，所以聯系了客戶方的應用工程師進行調試。調試完成後導入平臺，平臺調試成功，本次數據恢復成功。

raid5磁盤陣列有3塊硬盤掉線的解決方案-raid數據恢復案例