【伺服器資料恢復】HP MSA儲存raid5下vxfs檔案系統資料恢復

伺服器故障環境：

HP MSA某型號儲存，8塊SAS的硬碟組建RAID5磁碟陣列，其中包括1塊熱備盤。故障儲存中基於該RAID組的LUN均分配

給HP-Unix小機使用，上層做的LVM邏輯卷，儲存的資料為Oracle資料庫及OA服務端。

伺服器故障：

RAID5磁碟陣列中2塊磁碟未知原因離線，陣列中的熱備盤雖然成功啟用，RAID5磁碟陣列癱瘓，上層LUN不可用。

伺服器資料恢復過程：

1、由於儲存中RAID陣列崩潰是由於磁碟掉線導致的，拿到磁碟後先由硬體工程師對故障儲存中的所有磁碟做物理故障檢測

，檢測後沒有發現硬碟存在物理故障。使用壞道檢測工具檢測磁碟壞道，也沒有發現壞道。

2、將故障儲存中所有硬碟以只讀方式做完整的映象備份，後續的資料分析和資料恢復操作都基於映象檔案進行，避免資料

恢復操作可能對原始資料造成二次破壞。

部分備份資料：

3、由於故障儲存中所有磁碟不存在物理故障，也沒有發現壞道，所以磁碟離線原因就是某些磁碟讀寫不穩定。因為該品牌

儲存的RAID控制器針對磁碟的檢測策略比較嚴格，極大可能性把效能不穩定的磁碟認定為壞盤並踢出RAID組。一旦RAID

組中掉線的磁碟數量超過該RAID級別允許掉盤的最大數量，這個RAID組就會崩潰，上層基於RAID組的LUN也將不可用。

4、分析RAID組的資訊如條帶大小，磁碟順序及資料走向等，然後根據分析獲取到的raid資訊重構RAID組。經過分析發現

其中一塊盤的資料和其它盤不太一樣，初步判斷這塊盤就是熱備盤。分析其他資料盤（除了熱備盤）的底層，搞清楚Oracle

資料庫頁在每個磁碟中分佈的情況。

5、分析資料盤中的資料發現有一塊硬碟在同一個條帶上的資料和其他硬碟不一樣，初步判斷此盤是先掉線的，透過北亞企

安自主開發的RAID校驗程式對這個條帶做校驗，最終確定這塊盤就是先掉線的那塊硬碟。

6、由於LUN是基於RAID組的，將RAID組重構出來之後就開始分析LUN在RAID組中的分配情況以及LUN分配的資料塊MAP

。將每一個LUN的資料塊分佈MAP提取出來，然後針對這些資訊編寫程式解析所有LUN的資料MAP，然後根據資料MAP導

出所有LUN的資料。

7、分析生成出來的所有LUN，發現所有LUN中均包含HP-Unix的LVM邏輯卷資訊。嘗試解析每個LUN中的LVM資訊後發現

一共有3個LVM：其中1個LVM中劃分了一個LV，裡面存放OA伺服器端的資料；另外1個LVM中也劃分了一個LV，裡面存放

臨時備份資料；最後1個LVM也只劃分了一個LV，裡面存放Oracle資料庫檔案。北亞企安資料恢復工程師編寫LVM解釋程式

解釋每個LVM中的LV卷，但在解釋過程中程式出錯。

8、仔細分析程式報錯的原因，由開發工程師debug程式出錯的位置，並同時檢測恢復出來的LUN，檢測LMV邏輯卷的資訊

是否損壞。經過檢測發現LVM資訊已經損壞。嘗試人工修復損壞的區域，並同步修改LVM解釋程式重新解析LVM邏輯卷。

9、搭建HP-Unix環境，將解釋出來的LV卷對映到HP-Unix並嘗試掛載檔案系統，結果掛載檔案系統出錯。嘗試使用

“fsck –F vxfs” 命令修復vxfs檔案系統，修復完成後發現還是不能成功掛載。懷疑是底層vxfs檔案系統的部分後設資料已經破

壞。

10、分析解析出來的LV並根據VXFS檔案系統的底層結構校驗此檔案系統是否完整。分析結果發現底層VXFS檔案系統有問題

，儲存裝置癱瘓的時候檔案系統正在執行IO操作，部分檔案系統元檔案損壞。北亞企安資料恢復工程師手工修復這些損壞的

元檔案，直至VXFS檔案系統能夠被正常解析。

11、再次將修復好的LV卷掛載到HP-Unix小機上，嘗試Mount檔案系統，檔案系統成功掛載。

12、在HP-Unix小機上mount檔案系統後，將所有使用者資料均備份至指定的磁碟空間。

部分檔案目錄：

13、使用工具檢測每個Oracle資料庫檔案的完整性，沒有發現問題。使用北亞企安自主開發的Oracle資料庫檢測工具（檢

驗更嚴格）進行檢測，發現有部分Oracle資料庫檔案和日誌檔案校驗不一致。資料庫工程師對這部分檔案進行修復並再次

校驗，直到所有Oracle資料庫檔案校驗透過。

14、將恢復出來的Oracle資料庫附加到原始生產環境的HP-Unix伺服器中，啟動Oracle資料庫成功。

資料驗證：

在使用者方工程師的配合下，啟動Oracle資料庫和OA服務端。透過膝上型電腦上安裝的OA客戶端對最新的資料記錄以及歷史

資料記錄進行反覆驗證，並且安排使用者方公司不同部門人員進行遠端驗證。最終確認資料無誤，完整可用。本次資料恢復工

作完成。