HP存儲raid5兩塊硬盤離線lvm下vxfs文件系統恢復數據過程

故障描述

  HP FC MSA2000存儲，因爲RAID5陣列中出現2塊硬盤損壞並離線，而此時只有一塊熱備盤成功激活，所以致使RAID5陣列癱瘓，上層LUN沒法正常使用，用戶聯繫聯繫北亞數據，整個存儲空間由8塊450GB SAS的硬盤組成，其中7塊硬盤組成一個RAID5的陣列，剩餘1塊作成熱備盤使用。

  因爲存儲是由於RAID陣列中某些磁盤掉線，從而致使整個存儲不可用。所以接收到磁盤之後先對全部磁盤作物理檢測，檢測完後發現沒有物理故障。接着使用壞道檢測工具檢測磁盤壞道，發現也沒有壞道。

解決方法：

一、備份數據

  考慮到數據的安全性以及可還原性，在作數據恢復以前須要對全部源數據作備份，以防萬一其餘緣由致使數據沒法再次恢復。使用dd命令或winhex工具將全部磁盤都鏡像成文件。備份完部分數據以下圖：

 

二、分析故障緣由

  因爲前兩個步驟並無檢測到磁盤有物理故障或者是壞道，由此推斷多是因爲某些磁盤讀寫不穩定致使故障發生。由於HP MSA2000控制器檢查磁盤的策略很嚴格，一旦某些磁盤性能不穩定，HP MSA2000控制器就認爲是壞盤，就將認爲是壞盤的磁盤踢出RAID組。而一旦RAID組中掉線的盤到達到RAID級別容許掉盤的極限，那麼這個RAID組將變的不可用，上層基於RAID組的LUN也將變的不可用。目前初步瞭解的狀況爲基於RAID組的LUN有6個，均分配給HP-Unix小機使用，上層作的LVM邏輯卷，重要數據爲Oracle數據庫及OA服務端。

三、分析RAID組結構

  HP MSA2000存儲的LUN都是基於RAID組的，所以須要先分析底層RAID組的信息，而後根據分析的信息重構原始的RAID組。分析每一塊數據盤，發現4號盤的數據同其它數據盤不太同樣，初步認爲多是hot Spare盤。接着分析其餘數據盤，分析Oracle數據庫頁在每一個磁盤中分佈的狀況，並根據數據分佈的狀況得出RAID組的條帶大小，磁盤順序及數據走向等RAID組的重要信息。

四、分析RAID組掉線盤

  根據上述分析的RAID信息，嘗試經過北亞自主開發的RAID虛擬程序將原始的RAID組虛擬出來。但因爲整個RAID組中一共掉線兩塊盤，所以須要分析這兩塊硬盤掉線的順序。仔細分析每一塊硬盤中的數據，發現有一塊硬盤在同一個條帶上的數據和其餘硬盤明顯不同，所以初步判斷此硬盤多是最早掉線的，經過北亞自主開發的RAID校驗程序對這個條帶作校驗，發現除掉剛纔分析的那塊硬盤得出的數據是最好的，所以能夠明確最早掉線的硬盤了。

五、分析RAID組中的LUN信息

  因爲LUN是基於RAID組的，所以須要根據上述分析的信息將RAID組最新的狀態虛擬出來。而後分析LUN在RAID組中的分配狀況，以及LUN分配的數據塊MAP。因爲底層有6個LUN，所以只須要將每個LUN的數據塊分佈MAP提取出來。而後針對這些信息編寫相應的程序，對全部LUN的數據MAP作解析，而後根據數據MAP並導出全部LUN的數據。

 

六、解析LVM邏輯卷

  分析生成出來的全部LUN，發現全部LUN中均包含HP-Unix的LVM邏輯卷信息。嘗試解析每一個LUN中的LVM信息，發現其中一共有三套LVM，其中45G的LVM中劃分了一個LV，裏面存放OA服務器端的數據，190G的LVM中劃分了一個LV，裏面存放臨時備份數據。剩餘4個LUN組成一個2.1T左右的LVM，也只劃分了一個LV，裏面存放Oracle數據庫文件。編寫解釋LVM的程序，嘗試將每套LVM中的LV卷都解釋出來，但發現解釋程序出錯。

七、修復LVM邏輯卷

  仔細分析程序報錯的緣由，安排開發工程師debug程序出錯的位置，並同時安排高級文件系統工程師對恢復的LUN作檢測，檢測LVM信息是否會因存儲癱瘓致使LMV邏輯卷的信息損壞。通過仔細檢測，發現確實由於存儲癱瘓致使LVM信息損壞。嘗試人工對損壞的區域進行修復，並同步修改程序，從新解析LVM邏輯卷。

八、解析VXFS文件系統

  搭建HP-Unix環境，將解釋出來的LV卷映射到HP-Unix，並嘗試Mount文件系統。結果Mount文件系統出錯，嘗試使用「fsck –F vxfs」 命令修復vxfs文件系統，但修復結果仍是不能掛載，懷疑底層vxfs文件系統的部分元數據可能破壞，須要進行手工修復。

九、修復VXFS文件系統

  仔細分析解析出來的LV，並根據VXFS文件系統的底層結構校驗此文件系統是否完整。分析發現底層VXFS文件系統果真有問題，原來當時存儲癱瘓的同時此文件在系統正在執行IO操做，所以致使部分文件系統元文件沒有更新以及損壞。人工對這些損壞的元文件進行手工修復，保證VXFS文件系統可以正常解析。再次將修復好的LV卷掛載到HP-Unix小機上，嘗試Mount文件系統，文件系統沒有報錯，成功掛載。

十、恢復全部用戶文件

在HP-Unix機器上mount文件系統後，將全部用戶數據均備份至指定磁盤空間。全部用戶數據大小在1.2TB左右。部分文件目錄截圖以下：

 

十一、檢測數據庫文件是否完整

  使用Oracle數據庫文件檢測工具「dbv」檢測每一個數據庫文件是否完整，發現並無錯誤。再使用北亞自主研發的Oracle數據庫檢測工具（檢驗更嚴格），發現有部分數據庫文件和日誌文件校驗不一致，安排高級數據庫工程師對此類文件進行修復，並在次校驗，直到全部文件校驗均徹底經過。

十二、啓動Oracle數據庫

  因爲咱們提供的HP-Unix環境沒有此版本的Oracle數據，所以和用戶協調將原始生成環境帶至北亞數據恢復中心，而後將恢復的Oracle數據庫附加到原始生產環境的HP-Unix服務器中，嘗試啓動Oracle數據庫，Oracle數據庫啓動成功。部分截圖以下：

 

1三、數據驗證

  由用戶方配合，啓動Oracle數據庫，啓動OA服務端，在本地筆記本安裝OA客戶端。經過OA客戶端對最新的數據記錄以及歷史數據記錄進行驗證，而且有用戶安排遠程不一樣部門人員進行遠程驗證。最終數據驗證無誤，數據完整，數據恢復成功。

因爲故障發生後保存現場環境良好，沒用作相關危險的操做，對後期的數據恢復有很大的幫助。整個數據恢復過程當中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間內完成整個數據恢復，恢復的數據用戶方也至關滿意，Oracle數據庫服務，OA服務端等全部服務可以正常啓動。