服務器存儲故障：
某單位同友存儲，存儲設備中若干磁盤組建了raid5磁盤陣列。未知原因導致存儲設備崩潰無法啟動，raid5陣列上層的虛擬機全部丟失，其中存放了重要數據的3臺虛擬機需要恢復。

服務器存儲數據恢復過程：
1、磁盤鏡像過程就不贅述了。通過與用戶方的溝通以及對raid陣列的分析，獲悉故障存儲的存儲結構：若干物理磁盤組成一個存儲池，劃分了多個lun，其中需要恢復的那3臺虛擬機在lun1。
存儲結構：

北亞企安數據恢復——同友存儲數據恢復

2、嘗試對故障存儲中raid5陣列進行分析重組，發現故該raid5陣列缺失2塊硬盤，熱備盤已經啟用。
基于現在掌握的信息，可以還原當時故障發生過程：raid5陣列中第一塊硬盤掉線后，熱備盤自動啟動替換掉線硬盤。當第二塊硬盤掉線后，raid5陣列處于降級狀態。當第三塊硬盤掉線，raid5陣列崩潰。
通常這種情況是無法通過校驗直接獲取丟失硬盤的數據，只能嘗試使用磁盤同等大小的全0鏡像進行重組（使用全0鏡像組建的raid，文件系統結構會被嚴重破壞，相當于每個條帶都會缺失兩個塊的數據，所以一般情況下不建議使用全0鏡像組建raid。）
重建raid：

北亞企安數據恢復——同友存儲數據恢復

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

北亞企安數據恢復——同友存儲數據恢復

4、導出LUN內所有虛擬機并嘗試啟動，由于操作系統被破壞，虛擬機無法成功啟動。
5、由于虛擬機無法啟動，只能對虛擬機內的文件進行提取，但虛擬機內的多數文件被破壞嚴重，只有少部分文件可用，只好嘗試其他數據恢復方案。
6、本案例中需要恢復數據的虛擬機中有mysql數據庫，于是北亞企安數據恢復工程師嘗試通過利用數據庫底層存儲的特殊性掃描數據頁的方案來提取數據。在找到有數據庫的虛擬機后，發現該虛擬機啟用快照。父盤和快照文件都損壞的情況下常規合并操作無法完成，使用北亞企安自主研發的VMFS快照合并程序進行快照合并。

北亞企安數據恢復——同友存儲數據恢復

7、根據mysql數據頁特征掃描數據頁并導出（innodb引擎的數據庫可以使用此方案，myisam引擎的數據庫無“數據頁”概念），分析系統表獲取各用戶表信息，根據各個表的id進行數據頁分割。
8、因為數據庫使用時間已久，表結構曾多次變更，在存儲損壞后系統表中也有部分數據丟失，記錄提取過程很不順利。
9、首先獲取最初版本數據庫各個表的表結構：合并快照前的父盤因為寫入較早，使用第一塊掉線盤進行校驗獲取到這個文件的完整數據，然后提取出其中的數據庫各個表的表結構。用戶方提供了最新版的數據庫建表腳本。
10、分別使用兩組不同表結構對數據記錄進行提取，導入數據恢復環境中的mysql數據庫內，剔除各個表中因為表結構變更造成的亂碼數據，最后將兩組數據分別導出為.sql文件。
11、因為兩個版本的數據庫的表結構不同，所以聯系了用戶方的應用工程師進行調試，調試完成后導入平臺，平臺調試成功，用戶方經過檢測后認可本次數據恢復結果。

審核編輯 黃宇