天天看點

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的資料恢複如下:

圖一:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

  3、恢複oracle asm資料

  (1) asm磁盤組修複解析

  對eva存儲層恢複出來的lun進行分析,重組asm磁盤組,并對asm磁盤組進行解析。

總共有13個lun,通過分析每個lun前端的結構資料,可以根據asm磁盤頭結構來區分哪些lun是屬于asm磁盤組的。通過分析,總共有2套asm磁盤組。每個磁盤組包含的lun中分區的情況如下:

圖二:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

圖三:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

  

通過asm結構解析工具,對每個磁盤組進行解析和修複。可以解析出此asm中存儲的所有資料庫檔案。

圖四:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

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

對解析出的資料庫檔案,分别按檔案類型分組導出。對導出的檔案進行初步檢測。

圖五:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

  通過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共享的方式挂載到虛拟主機上,再将虛拟機一個一個的添加到清單。恢複的部分虛拟機檔案如下:

圖六:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

  2、驗證vmfs虛拟機

通過nfs将所有虛拟機都添加到虛拟主機以後,将所有虛拟機都加電開機,發現都能啟動系統。将所有虛拟機都開機進入系統,驗證虛拟機裡面的資料都沒問題。虛拟機的所有資料都恢複成功。部分虛拟機開機如下:

圖七:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

  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對導出的資料檔案進行實體結構檢測,以确定檔案導出完好。

圖八:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

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

  (2) 挂載啟動資料庫

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

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

  因為原來資料庫執行個體是有2個,并且是使用的asm存儲。是以在建立資料庫執行個體時,要按照原來配置和命名。

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

  5、修複oracle資料庫

  故障修複

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

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

圖九:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

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

圖十:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

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

  七、移交資料

  以及運作情況

  1、移交vmware虛拟機檔案和oracle資料庫檔案

  驗證所有資料沒有問題後,将vmware虛拟機檔案和oracle資料庫檔案拷貝至兩塊3tb的希捷硬碟中。然後再将拷貝好的資料移交給客戶。

  2、運作情況

客戶接受資料後,将資料上傳至背景,經檢測觀察,程式可正常運作,無問題。運作情況如下面所示。

圖十一:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

圖十二:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

圖十三:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

運作規定

圖十四:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

圖十五:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

運作變更摘要

圖十六:

EVA 4400存儲硬碟故障導緻資料丢失怎麼恢複?

  八、資料恢複結論

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