EVA系列儲存是一款以虛擬化儲存為實現目的的HP中高階儲存裝置，平時資料會不斷的遷移，加上任務通常較為繁重，所以磁碟的負載相對是較重的，也是很容易出現故障的。EVA是依靠大量磁碟的冗餘空間，以及故障後rss冗餘磁碟動態遷移來實現整個儲存的資料保護，但隨著越來越多的磁碟掉線，這種保護會接近臨界，直至崩潰。下面以EVA儲存故障為例，講解EVA 4400儲存資料恢復。

　　一、故障描述

　　整個EVA儲存結構是由一臺EVA4400控制器、EVA擴充套件櫃及若干FC磁碟組成。由於磁碟故障導致儲存中LUN不可用，致使上層應用無法正常使用。

　　二、檢測磁碟

　　由於EVA 4400是因為某些磁碟故障導致整個儲存不可用，因此接收到磁碟以後先對所有磁碟做物理檢測，檢測完後發現磁碟並沒有物理故障。接著使用壞道檢測工具檢測磁碟壞道，也並沒有發現大量的壞道。

　　三、備份資料

　　考慮到資料的安全性以及可還原性，在做資料恢復之前需要對所有源資料做備份，以確保源資料的安全。使用Winhex將所有源磁碟都備份到指定的目標空間中。

　　四、故障分析

　　1、分析故障原因

　　由於前兩個步驟並沒有檢測到磁碟有物理故障或者是壞道，由此推斷可能是由於某些磁碟讀寫不穩定導致故障發生。因為EVA控制器檢查磁碟的策略很嚴格，一旦某些磁碟效能不穩定，EVA控制器就認為是壞盤，就將認為是壞盤的磁碟踢出磁碟組。而一旦某個LUN的同一個條帶中掉線的盤到達極限，那麼這個LUN將變的不可用。也就是如果EVA中所有的LUN都包含這些掉線的盤，那麼這些LUN都會受影響。所以部分磁碟故障都會導致整個儲存無法正常使用。

　　2、分析LUN的結構

　　HP-EVA的LUN都是以RAID條目的形式儲存資料的，EVA將每個磁碟的不同塊組成一個RAID條目，RAID條目的型別可以有很多種。我們需要分析出組成LUN的RAID條目型別，以及這個RAID條目是由哪些盤的哪些塊組成。這些資訊都存放在LUN_MAP中，每個LUN都有一份LUN_MAP。EVA將LUN_MAP分別存放在不同的磁碟中，使用一個索引來指定其位置。因此去每個磁碟中找這個指向LUN_MAP的索引就可以找到現存LUN的資訊了。

　　3、分析掉線磁碟

　　在前面的故障分析中說了，雖然磁碟沒有明顯的物理故障，也沒有磁碟壞道。但還是會因為效能的原因從EVA磁碟組中脫離。而這些脫離的磁碟中都存放的是一些舊的資料，因此在生成資料的時候需要將這些磁碟都排除掉。但是如何判斷哪些磁碟是掉線的呢？由於LUN的RAID結構大多都是RAID5，只需要將一個LUN的RAID條目通過RAID5的校驗演算法算出校驗值，再和原有的校驗值做比較就可以判斷這個條目中是否有掉線盤。而將一個LUN的所有LUN_MAP都校驗一遍就可以知道這個LUN中哪些RAID條目中有掉線盤。而這些RAID條目中都存在的那個盤就一定是掉線盤。排除掉線盤，然後根據LUN_MAP恢復所有LUN的資料即可。

　　五、恢復資料

　　1、編寫資料恢復程式

　　上述的故障分析以及解決思路最終都需要使用程式設計來實現。編寫掃描LUN_MAP的程式Scan_Map.exe，掃描全部LUN_MAP，結合人工分析得出最精確的LUN_MAP。編寫檢測RAID條目的程式Chk_Raid.exe，檢測所有LUN中掉線的磁碟，結合人工分析排除掉線的磁碟。編寫LUN資料恢復程式Lun_Recovery.exe，結合LUN_MAP恢復所有LUN資料。

　　2、恢復所有LUN資料

　　根據編寫好的程式去實現不同的功能，最後使用Lun_Recovery.exe結合LUN_MAP恢復所有LUN的資料。然後人工核對每個LUN，確認是否和甲方工程師描述的一致。部分LUN的資料恢復如下圖：

　3、恢復ORACLE ASM資料

　　(1)     ASM磁碟組修復解析

　　對EVA儲存層恢復出來的LUN進行分析，重組ASM磁碟組，並對ASM磁碟組進行解析。

　　總共有13個LUN，通過分析每個LUN前端的結構資料，可以根據ASM磁碟頭結構來區分哪些LUN是屬於ASM磁碟組的。通過分析，總共有2套ASM磁碟組。每個磁碟組包含的LUN中分割槽的情況如下圖：

通過北亞自主開發的ASM結構解析工具，對每個磁碟組進行解析和修復。可以解析出此ASM中儲存的所有資料庫檔案。

　(2)  資料庫檔案解析匯出

　　對解析出的資料庫檔案，分別按檔案型別分組匯出。對匯出的檔案進行初步檢測。

通過ASM解析工具恢復出所有的資料庫檔案。

　　六、驗證資料

　　根據甲方工程師描述所有LUN的資料可以分成兩大部份，一部份是Vmware的虛擬機器，一部分是ORACLE上的ASM磁碟組資料，ASM磁碟組中存放的是Oracle的dbf資料庫檔案。由於我們恢復的是LUN，無法看到裡面的檔案，因此需要將這些LUN同過人工的核對哪些LUN是存放Vmware的資料，哪些是ASM裝置，然後將LUN掛載到不同的驗證環境中驗證恢復的資料是否完整。

　　1、部署Vmware虛擬機器的驗證環境

　　在一臺dell的伺服器上安裝了ESX5.5虛擬主機環境，然後通過iSCSI的方式將恢復的LUN掛載到虛擬主機上。在VMware vSphere Client 上掃描vmfs卷，但是發現客戶的虛擬主機是ESX4.0的版本，可能因為版本的原因無法直接掃描到vmfs卷，於是換一種驗證方式。將所有符合vmware虛擬機器的LUN裡面的虛擬機器檔案都生成出來，然後通過NFS共享的方式掛載到虛擬主機上，再將虛擬機器一個一個的新增到清單。恢復的部分虛擬機器檔案如下圖：

2、驗證vmfs虛擬機器

　　通過NFS將所有虛擬機器都新增到虛擬主機以後，將所有虛擬機器都加電開機，發現都能啟動系統。將所有虛擬機器都開機進入系統，驗證虛擬機器裡面的資料都沒問題。虛擬機器的所有資料都恢復成功。部分虛擬機器開機如下：

3、部署Oracle資料庫的驗證環境

　　為了ASM的恢復測試和後期的資料驗證工作，需要先搭建好oracle 環境。

　　根據甲方工程師提供的環境資訊為linux，於是需要搭建同架構的相容版本Oracle環境。

　　以下是安裝環境的簡單步驟介紹：

　　1. 環境檢測

　　# uname -all

　　然後檢查各部分儲存空間資訊，保證空間足夠。

　　2. 檢測安裝依賴包

　　根據安裝說明“  b19068.pdf  ”，檢查 oracle10g 所需的補丁包。

　　檢測：

　　# swlist-l bundle |grep "GOLD"

　　# swlist-l patch |grep PHNE_31097

　　如果沒有檢測到的，需要到官方網站下載並安裝。 安裝補丁包：

　　swinstall -s /patchCD/GOLDQPK11i -x autoreboot=true -x patch_match_target=true

　　3. 建立使用者及組

　　#groupadd dba

　　#useradd -g dba -d /home/oracle oracle

　　#passwd oracle

　　4. 建立目錄並修改許可權

　　建立目錄：

　　#mkdir –p/opt/oracle/product/10.2/oracledb

　　#chown -R oracle:dba/opt/oracle

　　修改許可權：

　　#chown oracle:dba/usr/oracle_inst/database/

　　#chmod 755/usr/oracle_inst/database/

　　5. 設定環境變數

　　vi /home/oracle/.profile

　　6. 安裝oracle

　　Oracle的安裝要求起圖形介面，所以要先測試影象介面能正常啟動。

　　#exoprt  DISPLAY=192.168.0.1.0:0

　　$./runInstaller

　　影象介面起來之後，只安裝軟體，不安裝例項。

　　7. 測試資料庫連線

　　#su - oracle

　　$sqlplus / as syssdba

　　4、驗證Oracle資料庫

　　(1)  驗證資料庫檔案結構

　　通過相同版本的oracle 官方檢測工具DBV對匯出的資料檔案進行物理結構檢測，以確定檔案匯出完好。

通過對所有資料檔案的驗證，確定所有檔案結構正確，沒有結構性損壞。

　　(2)  掛載啟動資料庫

　　在上面資料庫檔案物理結構驗證通過後，進行啟動資料庫，是資料庫驗證的最常用手段和步驟。

　　通過一些遷移資料庫的手段，修改控制檔案中的路徑，使oracle識別到這些資料庫資料檔案，然後按oracle正常步驟啟動資料庫。

　　因為原來資料庫例項有2個，並且是使用的ASM儲存。所以在建立資料庫例項時，要按照原來配置和命名。

　　在此環境下直接啟動由於引數配置和資料檔案路徑變動，造成啟動報錯。需要對其進行修復。

　　5、修復Oracle資料庫

　　故障修復

　　通過一些遷移資料庫的手段，修改控制檔案中的路徑，來讓oracle識別到這些資料庫資料檔案，然後使oracle資料庫按正常步驟啟動。

　　以下是dmis資料庫啟動的截圖：

以下是gsm資料庫啟動的截圖：

從此啟動過程可以看出，整個啟動過程正常進行，沒有任何報錯，基本說明資料庫完好恢復。

　　七、移交資料

　　以及執行情況

　　1、移交vmware虛擬機器檔案和Oracle資料庫檔案

　　驗證所有資料沒有問題後，將vmware虛擬機器檔案和Oracle資料庫檔案拷貝至兩塊3TB的希捷硬碟中。然後再將拷貝好的資料移交給客戶。

　　2、執行情況

　　客戶接受資料後，將資料上傳至後臺，經檢測觀察，程式可正常執行，無問題。執行情況如下面所示。

執行規定

　　執行變更摘要

八、資料恢復結論

　　由於故障發生後儲存現場環境良好，沒用做相關危險的操作，對後期的資料恢復有很大的幫助。整個資料恢復過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間內完成整個資料恢復，恢復的資料甲方也相當滿意。

九、專案成員列表