面對HP MSA儲存中硬碟掉線的情況，學會這種解決方式至關緊要

一、 HP   MSA 儲存 裝置資訊

1、 儲存 空間 由8塊 450 GB SAS的硬碟組成 。

2、 7塊硬碟組成一個RAID5的陣列，1塊 作為 熱 備盤 。

二、 HP   MSA 儲存 裝置故障描述

1 、 RAID5 陣列中出現 2 塊硬碟損壞，而此時只有一塊熱備盤成功啟用，因此導致 RAID5 陣列癱瘓，上層 LUN 無法正常使用。

2 、 RAID 陣列中某些磁碟掉線，導致整個儲存不可用。因此 需要 先對所有磁碟做物理檢測，檢測完後 確認硬碟無 物理故障。接著使用壞道檢測工具檢測磁碟壞道，發現也 無 壞道。

三 、 HP   MSA 儲存 備份資料

考慮到資料的安全性以及可還原性，在做資料恢復之前需要對所有源資料做備份，以防萬一其他原因導致資料無法再次恢復。使用dd 命令或 winhex 工具將所有磁碟都映象成檔案 。 備份完部分資料如下圖：

四 、 HP   MSA 儲存 故障分析

1 、分析故障原因

經 推斷可能是由於某些磁碟讀寫不穩定導致故障發生。因為HP  MSA2000 控制器檢查磁碟的策略很嚴格，一旦某些磁碟效能不穩定， HP  MSA2000 控制器就認為是壞盤，就將認為是壞盤的磁碟踢出 R AID 組。而一旦 R AID 組中掉線的盤到達到 RAID 級別允許掉盤的極限，那麼這個 RAID 組將變的不可用，上層基於 RAID 組的 LUN 也將變的不可用。目前初步瞭解的情況為基於 RAID 組的 LUN 有 6 個，均分配給HP-Unix 小機使用，上層做的 LVM 邏輯卷，重要資料為 Oracle 資料庫及 OA 服務端。

2 、分析 RAID 組結構

HP  MSA2000 儲存的 LUN 都是基於 RAID 組的，因此需要先分析底層 RAID 組的資訊，然後根據分析的資訊重構原始的 RAID 組。分析每一塊資料盤， 發現4 號盤的資料同其它資料盤不太一樣，初步認為可能是 hot  Spare 盤。接著分析其他資料盤，分析 Oracle 資料庫頁在每個磁碟中分佈的情況，並根據資料分佈的情況得出 RAID 組的條帶大小，磁碟順序及資料走向等 RAID 組的重要資訊。

3 、分析RAID 組掉線盤 先後順序

根據上述分析的 RAID 資訊，嘗試通過北亞自主開發的 RAID 虛擬程式將原始的 RAID 組虛擬出來 。但由於整個RAID 組中一共掉線兩塊盤，因此需要分析這兩塊硬碟掉線的順序。仔細分析每一塊硬碟中的資料，發現有一塊硬碟在同一個條帶上的資料和其他硬碟明顯不一樣，因此初步判斷此硬碟可能是最先掉線的，通過北亞自主開發的 RAID 校驗程式對這個條帶做校驗，發現除掉剛才分析的那塊硬碟得出的資料是最好的，因此可以明確最先掉線的硬碟了。

4、 分析RAID 組中的 LUN 資訊

首先 分析LUN 在 RAID 組中的分配情況，以及 LUN 分配的資料塊 MAP 。由於底層有 6 個 LUN ，因此只需要將每一個 LUN 的資料塊分佈 MAP 提取出來。然後針對這些資訊編寫相應的程式，對所有 LUN 的資料 MAP 做解析，然後根據資料 MAP 並匯出 所有 LUN 的資料。

五 、 HP   MSA 儲存 LV M 邏輯卷及VXFS 檔案系統修復

1 、 解析LV M 邏輯卷

分析生成出來的所有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 卷都解釋出來，但發現解釋程式出錯。

2 、修復 LV M 邏輯卷

仔細分析程式報錯的原因，安排開發工程師debug 程式出錯的位置，並同時安排高階檔案系統工程師對恢復的 LUN 做檢測，檢測 LVM 資訊是否會因儲存癱瘓導致 LMV 邏輯卷的資訊損壞。經過仔細檢測，發現確實因為儲存癱瘓導致 LVM 資訊損壞。嘗試人工對損壞的區域進行修復，並同步修改程式，重新解析 LVM 邏輯卷。

3 、 解析VXFS 檔案系統

搭建HP -Unix環境，將解釋出來的LV卷對映到HP-Unix，並嘗試Mount檔案系統。結果Mount檔案系統出錯，嘗試使用“fsck –F vxfs” 命令修復vxfs檔案 系統，但修復結果還是不能掛載，懷疑底層vxfs檔案系統的部分後設資料可能破壞，需要進行手工修復。

4 、修復 VXFS 檔案系統

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

六 、 檢測Oracle 資料庫檔案並啟動資料庫

1 、恢復 Oracle 資料庫檔案

在HP-Unix 機器上 mount 檔案系統後，將所有使用者資料均備份至指定磁碟空間。所有使用者資料大小在 1.2TB 左右。部分檔案目錄截圖如下：

2 、檢測 Oracle 資料庫檔案是否完整

使用Oracle 資料庫檔案檢測工具 “dbv” 檢測每個資料庫檔案是否完整，發現並沒有錯誤。再使用北亞自主研發的 Oracle 資料庫檢測工具（檢驗更嚴格），發現有部分資料庫檔案和日誌檔案校驗不一致，安排高階資料庫工程師對此類檔案進行修復，並在次校驗，直到所有檔案校驗均完全通過。

3 、啟動 Oracle 資料庫

由於我們提供的HP-Unix 環境沒有此版本的 Oracle 資料，因此 需要使用者的原始環境 ，將恢復的Oracle 資料庫附加到原始生產環境的 HP-Unix 伺服器中，嘗試啟動 Oracle 資料庫， Oracle 資料庫啟動成功。部分截圖如下：

七 、 HP   MSA 儲存 資料驗證

由使用者方 的積極 配合，啟動Oracle 資料庫，啟動 OA 服務端，在本地筆記本安裝 OA 客戶端。通過 OA 客戶端對最新的資料記錄以及歷史資料記錄進行驗證，並且有使用者安排遠端不同部門人員進行遠端驗證。最終資料驗證無誤，資料完整， 至此 資料恢復 工作結束 。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31380569/viewspace-2670172/，如需轉載，請註明出處，否則將追究法律責任。