EVA4400存儲(chǔ)虛擬機(jī)+數(shù)據(jù)庫數(shù)據(jù)恢復(fù)成功案例

一、故障描述

整個(gè)EVA存儲(chǔ)結(jié)構(gòu)是由一臺(tái)EVA4400控制器，三臺(tái)EVA4400擴(kuò)展柜和28塊FC 300G硬盤構(gòu)成的。由于兩塊磁盤掉線導(dǎo)致存儲(chǔ)某些LUN不可用，某些LUN丟失。由于EVA4400是因?yàn)槟承┐疟P掉線，從而導(dǎo)致整個(gè)存儲(chǔ)不可用。因此接收到磁盤以后北亞工程師先對(duì)所有磁盤做物理檢測(cè)，檢測(cè)完后發(fā)現(xiàn)沒有物理故障。接著使用壞道檢測(cè)工具檢測(cè)磁盤壞道，發(fā)現(xiàn)也沒有壞道。磁盤壞道檢測(cè)日志如下：
圖一：

二、備份數(shù)據(jù)

考慮到數(shù)據(jù)的安全性以及可還原性，在做數(shù)據(jù)恢復(fù)之前需要對(duì)所有源數(shù)據(jù)做備份，以防萬一操作不當(dāng)導(dǎo)致數(shù)據(jù)無法再次恢復(fù)。使用winhex將所有磁盤都鏡像成文件，源磁盤的內(nèi)容數(shù)量多，在做數(shù)據(jù)備份的時(shí)候要花費(fèi)很長(zhǎng)時(shí)間。備份完部分?jǐn)?shù)據(jù)如下：
圖二：

三、故障分析及恢復(fù)過程

1、分析故障原因
由于前兩個(gè)步驟并沒有檢測(cè)到磁盤有物理故障或者是壞道，由此推斷可能是由于某些磁盤讀寫不穩(wěn)定導(dǎo)致故障發(fā)生。因?yàn)镋VA控制器檢查磁盤的策略很嚴(yán)格，一旦某些磁盤性能不穩(wěn)定，EVA控制器就認(rèn)為是壞盤，就將認(rèn)為是壞盤的磁盤踢出磁盤組。而一旦某個(gè)LUN的同一個(gè)條帶中掉線的盤到達(dá)極限，那么這個(gè)LUN將不可用。即如果EVA中所有的LUN都包含這些掉線的盤，所有LUN都會(huì)受影響。掉線兩塊盤導(dǎo)致整個(gè)存儲(chǔ)的LUN都不可用的情況就很正常了。而目前的情況是現(xiàn)存8個(gè)LUN，損壞7個(gè)LUN，丟失6個(gè)LUN。需要恢復(fù)所有LUN的數(shù)據(jù)。
2、分析LUN的結(jié)構(gòu)
HP-EVA的LUN都是以RAID條目的形式存儲(chǔ)數(shù)據(jù)的，EVA將每個(gè)磁盤的不同塊組成一個(gè)RAID條目，RAID條目的類型可以有很多種。我們需要分析出組成LUN的RAID條目類型，以及這個(gè)RAID條目是由哪些盤的哪些塊組成。這些信息都存放在LUN_MAP中，每個(gè)LUN都有一份LUN_MAP。EVA將LUN_MAP分別存放在不同的磁盤中，使用一個(gè)索引來指定其位置。因此去每個(gè)磁盤中找這個(gè)指向LUN_MAP的索引就可以找到現(xiàn)存LUN的信息了。
3、分析丟失的LUN
雖然磁盤中記錄了指向LUN_MAP的索引，但是它只記錄現(xiàn)存的LUN，丟失的LUN是不會(huì)記錄索引的。由于EVA中刪除一個(gè)LUN只會(huì)清除這個(gè)LUN的索引，而不會(huì)清除這個(gè)LUN的LUN_MAP。這時(shí)需要掃描所有磁盤找到所有符合LUN_MAP的數(shù)據(jù)塊，然后排除掉現(xiàn)有的LUN_MAP，剩下的LUN_MAP也不一定全是刪除的，也有一些是以前舊的，但此時(shí)是無法在LUN_MAP中篩選了，只能通過程序?qū)⑺蠰UN_MAP的數(shù)據(jù)都恢復(fù)出來，人工的去核對(duì)哪些LUN是刪除的。
4、分析掉線磁盤
在前面的故障分析中說了，雖然磁盤沒有明顯的物理故障，也沒有磁盤壞道。但還是會(huì)因?yàn)樾阅艿脑驈腅VA磁盤組中脫離。而這些脫離的磁盤中都存放的是一些舊的數(shù)據(jù)，因此在生成數(shù)據(jù)的時(shí)候需要將這些磁盤都排除掉。但是如何判斷哪些磁盤是掉線的呢？由于LUN的RAID結(jié)構(gòu)大多都是RAID5，只需要將一個(gè)LUN的RAID條目通過RAID5的校驗(yàn)算法算出校驗(yàn)值，再和原有的校驗(yàn)值做比較就可以判斷這個(gè)條目中是否有掉線盤。而將一個(gè)LUN的所有LUN_MAP都校驗(yàn)一遍就可以知道這個(gè)LUN中哪些RAID條目中有掉線盤。而這些RAID條目中都存在的那個(gè)盤就一定是掉線盤。排除掉線盤，然后根據(jù)LUN_MAP恢復(fù)所有LUN的數(shù)據(jù)即可。
5、編寫數(shù)據(jù)恢復(fù)程序
上述的故障分析以及解決思路最終都需要使用編程來實(shí)現(xiàn)。編寫掃描LUN_MAP的程序Scan_Map.exe，掃描全部LUN_MAP，結(jié)合人工分析得出最精確的LUN_MAP。編寫檢測(cè)RAID條目的程序Chk_Raid.exe，檢測(cè)所有LUN中掉線的磁盤，結(jié)合人工分析排除掉線的磁盤。編寫LUN數(shù)據(jù)恢復(fù)程序Lun_Recovery.exe，結(jié)合LUN_MAP恢復(fù)所有LUN數(shù)據(jù)。
6、恢復(fù)所有LUN數(shù)據(jù)
根據(jù)編寫好的程序去實(shí)現(xiàn)不同的功能，最后使用Lun_Recovery.exe結(jié)合LUN_MAP恢復(fù)所有LUN的數(shù)據(jù)。然后人工核對(duì)每個(gè)LUN，確認(rèn)是否和甲方工程師描述的一致。部分LUN的數(shù)據(jù)恢復(fù)如下：
圖三：

四、數(shù)據(jù)驗(yàn)證

根據(jù)甲方工程師描述所有LUN的數(shù)據(jù)可以分成兩大部份，一部份是Vmware的虛擬機(jī)，一部分是HP-UX上的裸設(shè)備，裸設(shè)備里存放的是Oracle的dbf數(shù)據(jù)庫。由于我們恢復(fù)的是LUN，無法看到里面的文件，因此需要將這些LUN同過人工的核對(duì)哪些LUN是存放Vmware的數(shù)據(jù)，哪些是HP-UX的裸設(shè)備。然后將LUN掛載到不同的驗(yàn)證環(huán)境中驗(yàn)證恢復(fù)的數(shù)據(jù)是否完整。
1、部署Vmware虛擬機(jī)的驗(yàn)證環(huán)境
在一臺(tái)dell的服務(wù)器上安裝了ESXI5.5虛擬主機(jī)環(huán)境，然后通過iSCSI的方式將恢復(fù)的LUN掛載到虛擬主機(jī)上。但是在VMware vSphere Client 上掃描vmfs卷，沒有發(fā)現(xiàn)。后來發(fā)現(xiàn)客戶的虛擬主機(jī)是EXSI3.5的版本?？赡芤?yàn)榘姹镜脑驘o法直接掃描到vmfs卷，于是換一種驗(yàn)證方式。將所有符合vmware虛擬機(jī)的LUN里面的虛擬機(jī)文件都生成出來，然后通過NFS共享的方式掛載到虛擬主機(jī)上，然后將虛擬機(jī)一個(gè)一個(gè)的添加到清單?；謴?fù)的部分虛擬機(jī)文件如下：
圖四：

2、驗(yàn)證vmfs虛擬機(jī)
通過NFS將所有虛擬機(jī)都添加到虛擬主機(jī)以后，將所有虛擬機(jī)都加電開機(jī)，發(fā)現(xiàn)都能啟動(dòng)系統(tǒng)。由于沒有開機(jī)密碼無法確認(rèn)虛擬機(jī)里面的文件是否完整。后來甲方安排工程師通過遠(yuǎn)程到我們的服務(wù)器，將所有虛擬機(jī)都開機(jī)進(jìn)入系統(tǒng)，驗(yàn)證虛擬機(jī)里面的數(shù)據(jù)都沒問題。虛擬機(jī)的所有數(shù)據(jù)都恢復(fù)成功。部分虛擬機(jī)開機(jī)如下：
圖五：

3、部署Oracle數(shù)據(jù)庫的驗(yàn)證環(huán)境
為了裸設(shè)備恢復(fù)測(cè)試和后期的數(shù)據(jù)驗(yàn)證工作，需要先搭建好oracle 環(huán)境。
根據(jù)甲方工程師提供的環(huán)境信息為HP小機(jī)Itanium架構(gòu)，我公司HP小機(jī)為RX2660(Itanium 2), 是同架構(gòu)的兼容版本。于是計(jì)劃在此機(jī)器上安裝 oracle 單實(shí)例軟件。

操作系統(tǒng)：HP-UX B.11.31
數(shù)據(jù)庫：Oracle 10.2.0.1.0 Enterprise Edition - 64bit for HPUX

以下是安裝環(huán)境的簡(jiǎn)單步驟介紹：
（1） 環(huán)境檢測(cè)
# uname -all
HP-UX byhpux1 B.11.31 U ia64 1447541358 unlimited-user license
本機(jī)為IA64架構(gòu)，操作系統(tǒng)為 HP-UX ，版本為 B.11.31。
然后檢查各部分存儲(chǔ)空間信息，保證空間足夠。
（2） 檢測(cè)安裝依賴包
根據(jù)安裝說明“b19068.pdf”，檢查 oracle10g 所需的補(bǔ)丁包。
檢測(cè)：
# swlist-l bundle |grep "GOLD"
# swlist-l patch |grep PHNE_31097
如果沒有檢測(cè)到的，需要到官方網(wǎng)站下載并安裝。 安裝補(bǔ)丁包：
swinstall -s /patchCD/GOLDQPK11i -x autoreboot=true -x patch_match_target=true
（3）創(chuàng)建用戶及組
#groupadd dba
#useradd -g dba -d /home/oracle oracle
#passwd oracle
（4） 創(chuàng)建目錄并修改權(quán)限
創(chuàng)建目錄：
#mkdir –p/opt/oracle/product/10.2/oracledb
#chown -R oracle:dba/opt/oracle/frombyte.com

修改權(quán)限：
#chown oracle:dba/usr/oracle_inst/database/
#chmod 755/usr/oracle_inst/database/
（5）設(shè)置環(huán)境變量
vi /home/oracle/.profile
（6）安裝oracle
Oracle的安裝要求起圖形界面，所以要先測(cè)試圖像界面能夠正常啟動(dòng)。
#exoprt DISPLAY=192.168.0.1.0:0
$./runInstaller
圖像界面起來之后的安裝就比較簡(jiǎn)單了，這里只安裝軟件，不安裝實(shí)例。
（7）測(cè)試數(shù)據(jù)庫連接
#su - oracle
$sqlplus / as syssdba

4、驗(yàn)證Oracle數(shù)據(jù)庫
（1）掛載裸設(shè)備
由于有部分LUN是裸設(shè)備，而我們恢復(fù)的LUN都是以文件的形式存在。因此需要將文件形式的LUN掛載到HP-UX上。在HP-UX服務(wù)器上安裝iSCSI Initiator，安裝步驟如下：
檢測(cè)軟件包是否完整
#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的可執(zhí)行文件添加到PATH
#PATH=$PATH:/opt/iscsi/bin/frombyte.com
檢測(cè)iSCSI是否安裝成功
#iscsiutil -l
配置iSCSI的啟動(dòng)器名稱
#iscsituil /dev/iscsi -i -N iqn.2014-10-15:LUN
配置掛載目標(biāo)iSCSI設(shè)備
#iscsiutil -a -I 10.10.1.9
刪除目標(biāo)iscsi設(shè)備
#iscsiutil -d -I 10.10.1.9
驗(yàn)證目標(biāo)iSCSI是否掛載成功
#iscsiutil -pD
發(fā)現(xiàn)目標(biāo)target設(shè)備
#/usr/sbin/ioscan -H 255
為目標(biāo)創(chuàng)建設(shè)備文件
#/usr/sbin/insf -H 255
（2）導(dǎo)入外部VG信息
創(chuàng)建VG節(jié)點(diǎn)
#mkdir /dev/vgscope/frombyte.com
創(chuàng)建VG設(shè)備文件名
#mknod /dev/vgscope/group c 64 0x030000
查看PV是否正常
#pvdisplay -l /dev/dsk/c2t0d0/frombyte.com
將PV導(dǎo)入VG中
#vgimport -v /dev/vgscope /dev/dsk/c2t0d0
激活VG信息
#vgchange -a y vgscope
查看VG信息
#vgdisplay -v vgscope
圖六：

（3）修改LV名稱
由于是在新的環(huán)境上重建的VG，然后再將PV導(dǎo)入到新建的VG中。因此LV的名稱全部都改變了，需要手動(dòng)的去將LV的名稱都改成和以前一下的。
圖七：

因?yàn)樵瓉頂?shù)據(jù)庫實(shí)例是有2個(gè)，并且是使用的裸設(shè)備存儲(chǔ)。所以在創(chuàng)建數(shù)據(jù)庫實(shí)例時(shí)，要按按照原來配置和命名。
文件系統(tǒng)層面，在同時(shí)協(xié)助下，掛載了所有LV,并修改權(quán)限。
圖八：

安裝數(shù)據(jù)庫實(shí)例，根據(jù)原始配置，在客戶DBA協(xié)助下，安裝并識(shí)別到所有裸設(shè)備文件。
然后調(diào)整配置參數(shù)，檢測(cè)數(shù)據(jù)庫存儲(chǔ)狀態(tài)，為啟動(dòng)數(shù)據(jù)庫做準(zhǔn)備。

首先切換到實(shí)例 scope（最重要）。,啟動(dòng)數(shù)據(jù)庫。
SQL>startup mount;
SQL>select file#,error from v$recover_file; --查損壞的文件.
沒有損壞的文件。
SQL>ALTER DATABASE OPEN;
啟動(dòng)沒有報(bào)錯(cuò)，但是緩慢，之后查詢了用戶，隨機(jī)查詢了一個(gè)用戶的兩張表，數(shù)據(jù)結(jié)果集返回正常。然后連接突然中斷，重新連接，查看狀態(tài)為數(shù)據(jù)庫關(guān)閉。再啟動(dòng)數(shù)據(jù)庫，還是啟動(dòng)不了，會(huì)強(qiáng)制關(guān)閉。
經(jīng)過初步檢測(cè)和常規(guī)恢復(fù)庫狀態(tài)，不能修復(fù)此問題。

驗(yàn)證 NJYY 數(shù)據(jù)庫
將環(huán)境變量切換到另一個(gè)數(shù)據(jù)庫NJYY，open數(shù)據(jù)庫時(shí)報(bào)錯(cuò)內(nèi)存不足錯(cuò)誤,不能開啟數(shù)據(jù)庫。經(jīng)初步檢測(cè)檢測(cè)，數(shù)據(jù)文件沒有損壞。
SQL>startup mount;
SQL>select file#,error from v$recover_file;
SQL>ALTER DATABASE OPEN;
error 4030 detected in background process

5、修復(fù)Oracle數(shù)據(jù)庫
故障修復(fù)
對(duì)于scope數(shù)據(jù)庫，根據(jù)上面的操作和故障現(xiàn)象，初步判斷是undo表空間或者日志方面有問題。對(duì)數(shù)據(jù)文件做完整性和一致性檢測(cè)，結(jié)果只有一個(gè)undo01.dbf文件損壞。確定是undo表空間損壞。通過命令刪除掉損壞的undo表空間，又在原來位置重建。
檢測(cè)其他部分文件，沒有發(fā)現(xiàn)問題。重新啟動(dòng)數(shù)據(jù)庫，正常啟動(dòng)，做查詢數(shù)據(jù)，正常，做了完整性檢測(cè)，正常。
接著做imp數(shù)據(jù)庫全庫導(dǎo)出，經(jīng)過3個(gè)多小時(shí)正常導(dǎo)出全庫數(shù)據(jù)庫。
對(duì)于 NJYY數(shù)據(jù)庫，檢測(cè)到是內(nèi)存空間設(shè)置不對(duì)，經(jīng)過命令調(diào)整，數(shù)據(jù)庫恢復(fù)正常，能正常啟動(dòng)，正常使用。
最后做imp數(shù)據(jù)庫全庫導(dǎo)出，經(jīng)過4個(gè)多小時(shí)正常導(dǎo)出全庫數(shù)據(jù)庫。

具體驗(yàn)證
在完成初步驗(yàn)證之后，甲方要求其DBA和業(yè)務(wù)人員通過遠(yuǎn)程做數(shù)據(jù)庫進(jìn)一步具體驗(yàn)證。配合做了驗(yàn)證環(huán)境和各個(gè)數(shù)據(jù)庫的驗(yàn)證。
最終驗(yàn)證數(shù)據(jù)庫為完全恢復(fù)，沒有問題。
在驗(yàn)證數(shù)據(jù)之后，做數(shù)據(jù)遷移。考慮到數(shù)據(jù)庫的容量和恢復(fù)時(shí)間。選擇用expdp來做全庫數(shù)據(jù)的導(dǎo)出。因?yàn)閑xpdp的效率比exp的高些。
編寫好導(dǎo)出腳本，并在測(cè)試環(huán)境下測(cè)試沒有問題后，先對(duì)scope數(shù)據(jù)庫進(jìn)行導(dǎo)出。導(dǎo)出開始后24分鐘時(shí)，開始報(bào)錯(cuò)：
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
經(jīng)過查找原因，得出是因?yàn)閟ystem表空間已滿造成的。用expdp導(dǎo)出時(shí)會(huì)向system表空間里的SYSTEM.SYS_MTABLE_00003A964_IND_1表里加入導(dǎo)出記錄數(shù)據(jù).當(dāng)導(dǎo)出大量數(shù)據(jù)時(shí)，此表的數(shù)據(jù)量就會(huì)增大，當(dāng)達(dá)到system表空間的總?cè)萘繒r(shí)，就會(huì)報(bào)錯(cuò)。這里分析，表空間一般是會(huì)自動(dòng)增加容量的，那樣就不應(yīng)該報(bào)錯(cuò)。最后查詢出，system表空間是放在裸設(shè)備上的，容量為1G，且不可以增大。所以，就不能使用expdp工具做導(dǎo)出。 只能使用exp工具導(dǎo)出，雖然會(huì)慢一點(diǎn)，但是不會(huì)有system表空間不足的問題。
最后通過exp對(duì)scope做全庫導(dǎo)出，經(jīng)過6個(gè)多小時(shí)成功備份完成。備份文件達(dá) 172G。
對(duì)NJYY數(shù)據(jù)庫，做imp導(dǎo)出，經(jīng)過7個(gè)多小時(shí)正常導(dǎo)出全庫數(shù)據(jù)庫，備份文件達(dá)140G.接著對(duì)數(shù)據(jù)庫備份文件做了本地備份，作為安全冷備份。

五、移交數(shù)據(jù)

1、移交vmware虛擬機(jī)文件和Oracle dump文件
驗(yàn)證所有數(shù)據(jù)沒有問題后，將vmware虛擬機(jī)文件和Oracle dump文件拷貝至一塊2TB的希捷硬盤中。然后再將恢復(fù)出來的LUN數(shù)據(jù)拷貝至兩塊3TB的單盤中。來到甲方現(xiàn)場(chǎng)后先將vmware虛擬機(jī)文件和Oracle dump文件交給甲方后，甲方開始驗(yàn)證dump文件和vmware虛擬機(jī)文件。
2、將LUN數(shù)據(jù)鏡像到甲方的EVA4400存儲(chǔ)服務(wù)器上
由于甲方要求將所有LUN數(shù)據(jù)恢復(fù)到原環(huán)境中，因此需要重新配置HP-EVA4400，重新創(chuàng)建和以前一樣大小的LUN。然后通過winhex工具將恢復(fù)的LUN數(shù)據(jù)全部鏡像到EVA新建的LUN中。由于甲方的HP-EVA4400的控制器存在一些問題導(dǎo)致調(diào)試了很久才重置HP-EVA4400。鏡像完所有LUN數(shù)據(jù)后，甲方安排Oracle數(shù)據(jù)庫工程師驗(yàn)證恢復(fù)的Oracle是否正常。檢測(cè)后發(fā)現(xiàn)有兩個(gè)dbf文件丟失導(dǎo)致Oracle服務(wù)啟動(dòng)失敗，分析故障原因后發(fā)現(xiàn)，因?yàn)檫@兩個(gè)丟失的dbf在EVA故障之前是以文件的方式存在，后來在恢復(fù)的時(shí)候，將其恢復(fù)到LV里面去了。而甲方工程師在恢復(fù)LV的時(shí)候并沒有重建vg而是按照以前的vg_map恢復(fù)的所有LV。因此才會(huì)出現(xiàn)這個(gè)問題，解決辦法，重新創(chuàng)建兩個(gè)LV，然后從底層LUN中將這兩個(gè)文件取出，將其dd到新創(chuàng)建的LV中。再次啟動(dòng)Oracle服務(wù)，啟動(dòng)正常，問題解決。
由于故障發(fā)生后保存現(xiàn)場(chǎng)環(huán)境良好，沒有做相關(guān)危險(xiǎn)的操作，對(duì)后期的數(shù)據(jù)恢復(fù)有很大的幫助。整個(gè)數(shù)據(jù)恢復(fù)過程中雖然遇到好多技術(shù)瓶頸，但也都一一解決。最終在預(yù)期的時(shí)間內(nèi)完成整個(gè)數(shù)據(jù)恢復(fù)，恢復(fù)的數(shù)據(jù)甲方也相當(dāng)滿意。
日后數(shù)據(jù)安全建議
1、安排員工經(jīng)常巡視機(jī)房，發(fā)現(xiàn)有報(bào)警信息及時(shí)處理。
2、管理人員操作存儲(chǔ)要謹(jǐn)慎，避免誤操作導(dǎo)致數(shù)據(jù)丟失。
3、現(xiàn)場(chǎng)發(fā)現(xiàn)EVA控制器部分模塊不太穩(wěn)定，應(yīng)當(dāng)及時(shí)更換。
4、由于EVA存儲(chǔ)故障是由磁盤不穩(wěn)定引起的，而這部分磁盤應(yīng)該是同一批次的磁盤。因此，這些磁盤的性能也快到極限，如果有條件建議換掉這批磁盤。