EVA4400儲存虛擬機器+資料庫資料恢複成功案例

標籤：undle   存在   2.0   dump   恢複   狀態   功能   強制   size   

一、故障描述

整個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的資訊了。
3、分析丟失的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的資料即可。
5、編寫資料恢複程式
上述的故障分析以及解決思路最終都需要使用編程來實現。編寫掃描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.接著對Database Backup檔案做了本地備份，作為安全冷備份。

五、移交資料

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儲存虛擬機器+資料庫資料恢複成功案例