1. 程式人生 > >分享一例EVA 4400存儲硬盤故障數據恢復方案和數據恢復過程

分享一例EVA 4400存儲硬盤故障數據恢復方案和數據恢復過程

數據恢復 硬盤 存儲 故障

  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/frombyte,結合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/frombyte

  #passwd oracle

  4. 創建目錄並修改權限

  創建目錄:

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

  #chown -R oracle:dba/opt/oracle

  修改權限:

  #chown oracle:dba/usr/oracle_inst/database/frombyte.com

  #chmod 755/usr/oracle_inst/database/frombyte.com

  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、運行情況

客戶接受數據後,將數據上傳至後臺,經檢測觀察,程序可正常運行,無問題。運行情況如下面所示。

圖十一:

技術分享

圖十二:

技術分享

圖十三:

技術分享

運行規定

圖十四:

技術分享

圖十五:

技術分享

運行變更摘要

圖十六:

技術分享

  八、數據恢復結論

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


本文出自 “SUN” 博客,請務必保留此出處http://sun510.blog.51cto.com/9640486/1925857

分享一例EVA 4400存儲硬盤故障數據恢復方案和數據恢復過程