EVA4400存儲虛擬機+數據庫數據恢復成功案例
整個EVA存儲結構是由一臺EVA4400控制器，三臺EVA4400擴展櫃和28塊FC 300G硬盤構成的。由於兩塊磁盤掉線導致存儲某些LUN不可用，某些LUN丟失。由於EVA4400是因為某些磁盤掉線，從而導致整個存儲不可用。因此接收到磁盤以後北亞工程師先對所有磁盤做物理檢測，檢測完後發現沒有物理故障。接著使用壞道檢測工具檢測磁盤壞道，發現也沒有壞道。磁盤壞道檢測日誌如下：
圖一：
二、備份數據
考慮到數據的安全性以及可還原性，在做數據恢復之前需要對所有源數據做備份，以防萬一操作不當導致數據無法再次恢復。使用winhex將所有磁盤都鏡像成文件，源磁盤的內容數量多，在做數據備份的時候要花費很長時間。備份完部分數據如下：
三、故障分析及恢復過程
1、分析故障原因
由於前兩個步驟並沒有檢測到磁盤有物理故障或者是壞道，由此推斷可能是由於某些磁盤讀寫不穩定導致故障發生。因為EVA控制器檢查磁盤的策略很嚴格，一旦某些磁盤性能不穩定，EVA控制器就認為是壞盤，就將認為是壞盤的磁盤踢出磁盤組。而一旦某個LUN的同一個條帶中掉線的盤到達極限，那麽這個LUN將不可用。即如果EVA中所有的LUN都包含這些掉線的盤，所有LUN都會受影響。掉線兩塊盤導致整個存儲的LUN都不可用的情況就很正常了。而目前的情況是現存8個LUN，損壞7個LUN，丟失6個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的信息了。
雖然磁盤中記錄了指向LUN_MAP的索引，但是它只記錄現存的LUN，丟失的LUN是不會記錄索引的。由於EVA中刪除一個LUN只會清除這個LUN的索引，而不會清除這個LUN的LUN_MAP。這時需要掃描所有磁盤找到所有符合LUN_MAP的數據塊，然後排除掉現有的LUN_MAP，剩下的LUN_MAP也不一定全是刪除的，也有一些是以前舊的，但此時是無法在LUN_MAP中篩選了，只能通過程序將所有LUN_MAP的數據都恢復出來，人工的去核對哪些LUN是刪除的。
4、分析掉線磁盤
在前面的故障分析中說了，雖然磁盤沒有明顯的物理故障，也沒有磁盤壞道。但還是會因為性能的原因從EVA磁盤組中脫離。而這些脫離的磁盤中都存放的是一些舊的數據，因此在生成數據的時候需要將這些磁盤都排除掉。但是如何判斷哪些磁盤是掉線的呢？由於LUN的RAID結構大多都是RAID5，只需要將一個LUN的RAID條目通過RAID5的校驗算法算出校驗值，再和原有的校驗值做比較就可以判斷這個條目中是否有掉線盤。而將一個LUN的所有LUN_MAP都校驗一遍就可以知道這個LUN中哪些RAID條目中有掉線盤。而這些RAID條目中都存在的那個盤就一定是掉線盤。排除掉線盤，然後根據LUN_MAP恢復所有LUN的數據即可。
上述的故障分析以及解決思路最終都需要使用編程來實現。編寫掃描LUN_MAP的程序Scan_Map.exe，掃描全部LUN_MAP，結合人工分析得出最精確的LUN_MAP。編寫檢測RAID條目的程序Chk_Raid.exe，檢測所有LUN中掉線的磁盤，結合人工分析排除掉線的磁盤。編寫LUN數據恢復程序Lun_Recovery.exe，結合LUN_MAP恢復所有LUN數據。
6、恢復所有LUN數據
根據編寫好的程序去實現不同的功能，最後使用Lun_Recovery.exe結合LUN_MAP恢復所有LUN的數據。然後人工核對每個LUN，確認是否和甲方工程師描述的一致。部分LUN的數據恢復如下：
圖三：
四、數據驗證
根據甲方工程師描述所有LUN的數據可以分成兩大部份，一部份是Vmware的虛擬機，一部分是HP-UX上的裸設備，裸設備裏存放的是Oracle的dbf數據庫。由於我們恢復的是LUN，無法看到裏面的文件，因此需要將這些LUN同過人工的核對哪些LUN是存放Vmware的數據，哪些是HP-UX的裸設備。然後將LUN掛載到不同的驗證環境中驗證恢復的數據是否完整。
1、部署Vmware虛擬機的驗證環境
在一臺dell的服務器上安裝了ESXI5.5虛擬主機環境，然後通過iSCSI的方式將恢復的LUN掛載到虛擬主機上。但是在VMware vSphere Client 上掃描vmfs卷，沒有發現。後來發現客戶的虛擬主機是EXSI3.5的版本。可能因為版本的原因無法直接掃描到vmfs卷，於是換一種驗證方式。將所有符合vmware虛擬機的LUN裏面的虛擬機文件都生成出來，然後通過NFS共享的方式掛載到虛擬主機上，然後將虛擬機一個一個的添加到清單。恢復的部分虛擬機文件如下：
圖四：
2、驗證vmfs虛擬機
通過NFS將所有虛擬機都添加到虛擬主機以後，將所有虛擬機都加電開機，發現都能啟動系統。由於沒有開機密碼無法確認虛擬機裏面的文件是否完整。後來甲方安排工程師通過遠程到我們的服務器，將所有虛擬機都開機進入系統，驗證虛擬機裏面的數據都沒問題。虛擬機的所有數據都恢復成功。部分虛擬機開機如下：
圖五：
3、部署Oracle數據庫的驗證環境
為了裸設備恢復測試和後期的數據驗證工作，需要先搭建好oracle 環境。
根據甲方工程師提供的環境信息為HP小機Itanium架構，我公司HP小機為RX2660(Itanium 2), 是同架構的兼容版本。於是計劃在此機器上安裝 oracle 單實例軟件。
操作系統：HP-UX B.11.31
數據庫：Oracle 10.2.0.1.0 Enterprise Edition - 64bit for HPUX
以下是安裝環境的簡單步驟介紹：
（1） 環境檢測
# uname -all
HP-UX byhpux1 B.11.31 U ia64 1447541358 unlimited-user license
本機為IA64架構，操作系統為 HP-UX ，版本為 B.11.31。
然後檢查各部分存儲空間信息，保證空間足夠。
（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/frombyte.com
修改權限：
#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）掛載裸設備
由於有部分LUN是裸設備，而我們恢復的LUN都是以文件的形式存在。因此需要將文件形式的LUN掛載到HP-UX上。在HP-UX服務器上安裝iSCSI Initiator，安裝步驟如下：
檢測軟件包是否完整
#swlist -d @ /tmp/B.11.31.03d_iSCSI-00_B.11.31.03d_HP-UX_B.11.31_IA_PA.depot
安裝軟件包
#swinstall -x autoreboot=true -s /tmp/B.11.31.03d_iSCSI-00_B.11.31.03d_HP-UX_B.11.31_IA_PA.depot iSCSI-00
將iSCSI的可執行文件添加到PATH
#PATH=$PATH:/opt/iscsi/bin/frombyte.com
檢測iSCSI是否安裝成功
#iscsiutil -l
配置iSCSI的啟動器名稱
#iscsituil /dev/iscsi -i -N iqn.2014-10-15:LUN
配置掛載目標iSCSI設備
#iscsiutil -a -I 10.10.1.9
刪除目標iscsi設備
#iscsiutil -d -I 10.10.1.9
驗證目標iSCSI是否掛載成功
#iscsiutil -pD
發現目標target設備
#/usr/sbin/ioscan -H 255
為目標創建設備文件
#/usr/sbin/insf -H 255
（2）導入外部VG信息
創建VG節點
#mkdir /dev/vgscope/frombyte.com
創建VG設備文件名
#mknod /dev/vgscope/group c 64 0x030000
查看PV是否正常
#pvdisplay -l /dev/dsk/c2t0d0/frombyte.com
將PV導入VG中
#vgimport -v /dev/vgscope /dev/dsk/c2t0d0
激活VG信息
#vgchange -a y vgscope
查看VG信息
#vgdisplay -v vgscope
圖六：
（3）修改LV名稱
由於是在新的環境上重建的VG，然後再將PV導入到新建的VG中。因此LV的名稱全部都改變了，需要手動的去將LV的名稱都改成和以前一下的。
圖七：
因為原來數據庫實例是有2個，並且是使用的裸設備存儲。所以在創建數據庫實例時，要按按照原來配置和命名。
文件系統層面，在同時協助下，掛載了所有LV,並修改權限。
圖八：
安裝數據庫實例，根據原始配置，在客戶DBA協助下，安裝並識別到所有裸設備文件。
然後調整配置參數，檢測數據庫存儲狀態，為啟動數據庫做準備。
首先切換到實例 scope（最重要）。,啟動數據庫。
SQL>startup mount;
SQL>select file#,error from v$recover_file; --查損壞的文件.
沒有損壞的文件。
SQL>ALTER DATABASE OPEN;
啟動沒有報錯，但是緩慢，之後查詢了用戶，隨機查詢了一個用戶的兩張表，數據結果集返回正常。然後連接突然中斷，重新連接，查看狀態為數據庫關閉。再啟動數據庫，還是啟動不了，會強制關閉。
經過初步檢測和常規恢復庫狀態，不能修復此問題。
驗證 NJYY 數據庫
將環境變量切換到另一個數據庫NJYY，open數據庫時報錯內存不足錯誤,不能開啟數據庫。經初步檢測檢測，數據文件沒有損壞。
SQL>startup mount;
SQL>select file#,error from v$recover_file;
SQL>ALTER DATABASE OPEN;
error 4030 detected in background process
5、修復Oracle數據庫
故障修復
對於scope數據庫，根據上面的操作和故障現象，初步判斷是undo表空間或者日誌方面有問題。對數據文件做完整性和一致性檢測，結果只有一個undo01.dbf文件損壞。確定是undo表空間損壞。通過命令刪除掉損壞的undo表空間，又在原來位置重建。
檢測其他部分文件，沒有發現問題。重新啟動數據庫，正常啟動，做查詢數據，正常，做了完整性檢測，正常。
接著做imp數據庫全庫導出，經過3個多小時正常導出全庫數據庫。
對於 NJYY數據庫，檢測到是內存空間設置不對，經過命令調整，數據庫恢復正常，能正常啟動，正常使用。
最後做imp數據庫全庫導出，經過4個多小時正常導出全庫數據庫。
具體驗證
在完成初步驗證之後，甲方要求其DBA和業務人員通過遠程做數據庫進一步具體驗證。配合做了驗證環境和各個數據庫的驗證。
最終驗證數據庫為完全恢復，沒有問題。
在驗證數據之後，做數據遷移。考慮到數據庫的容量和恢復時間。選擇用expdp來做全庫數據的導出。因為expdp的效率比exp的高些。
編寫好導出腳本，並在測試環境下測試沒有問題後，先對scope數據庫進行導出。導出開始後24分鐘時，開始報錯：
ORA-39171: Job is experiencing a resumable wait.
ORA-01654: unable to extend index SYSTEM.SYS_MTABLE_00003A964_IND_1 by 8 in tablespace SYSTEM
經過查找原因，得出是因為system表空間已滿造成的。用expdp導出時會向system表空間裏的SYSTEM.SYS_MTABLE_00003A964_IND_1表裏加入導出記錄數據.當導出大量數據時，此表的數據量就會增大，當達到system表空間的總容量時，就會報錯。這裏分析，表空間一般是會自動增加容量的，那樣就不應該報錯。最後查詢出，system表空間是放在裸設備上的，容量為1G，且不可以增大。所以，就不能使用expdp工具做導出。 只能使用exp工具導出，雖然會慢一點，但是不會有system表空間不足的問題。
最後通過exp對scope做全庫導出，經過6個多小時成功備份完成。備份文件達 172G。
對NJYY數據庫，做imp導出，經過7個多小時正常導出全庫數據庫，備份文件達140G.接著對數據庫備份文件做了本地備份，作為安全冷備份。
五、移交數據
1、移交vmware虛擬機文件和Oracle dump文件
驗證所有數據沒有問題後，將vmware虛擬機文件和Oracle dump文件拷貝至一塊2TB的希捷硬盤中。然後再將恢復出來的LUN數據拷貝至兩塊3TB的單盤中。來到甲方現場後先將vmware虛擬機文件和Oracle dump文件交給甲方後，甲方開始驗證dump文件和vmware虛擬機文件。
2、將LUN數據鏡像到甲方的EVA4400存儲服務器上
由於甲方要求將所有LUN數據恢復到原環境中，因此需要重新配置HP-EVA4400，重新創建和以前一樣大小的LUN。然後通過winhex工具將恢復的LUN數據全部鏡像到EVA新建的LUN中。由於甲方的HP-EVA4400的控制器存在一些問題導致調試了很久才重置HP-EVA4400。鏡像完所有LUN數據後，甲方安排Oracle數據庫工程師驗證恢復的Oracle是否正常。檢測後發現有兩個dbf文件丟失導致Oracle服務啟動失敗，分析故障原因後發現，因為這兩個丟失的dbf在EVA故障之前是以文件的方式存在，後來在恢復的時候，將其恢復到LV裏面去了。而甲方工程師在恢復LV的時候並沒有重建vg而是按照以前的vg_map恢復的所有LV。因此才會出現這個問題，解決辦法，重新創建兩個LV，然後從底層LUN中將這兩個文件取出，將其dd到新創建的LV中。再次啟動Oracle服務，啟動正常，問題解決。
由於故障發生後保存現場環境良好，沒有做相關危險的操作，對後期的數據恢復有很大的幫助。整個數據恢復過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間內完成整個數據恢復，恢復的數據甲方也相當滿意。
日後數據安全建議
1、安排員工經常巡視機房，發現有報警信息及時處理。
2、管理人員操作存儲要謹慎，避免誤操作導致數據丟失。
3、現場發現EVA控制器部分模塊不太穩定，應當及時更換。
4、由於EVA存儲故障是由磁盤不穩定引起的，而這部分磁盤應該是同一批次的磁盤。因此，這些磁盤的性能也快到極限，如果有條件建議換掉這批磁盤。
EVA4400存儲虛擬機+數據庫數據恢復成功案例