一、故障描述
HP FC MSA2000存儲 整個存儲空間由8塊450GB SAS的硬碟組成，其中7塊硬碟組成一個RAID5的陣列，剩餘1塊做成熱備盤使用。由于RAID5陣列中出現2塊硬碟損壞，而此時隻有一塊熱備盤成功激活，是以導緻RAID5陣列癱瘓，上層LUN無法正常使用。
由于存儲是因為RAID陣列中某些磁盤掉線，進而導緻整個存儲不可用。是以接收到磁盤以後先對所有磁盤做實體檢測，檢測完後發現沒有實體故障。接着使用壞道檢測工具檢測磁盤壞道，發現也沒有壞道。
二、備份資料
考慮到資料的安全性以及可還原性，在做資料恢複之前需要對所有源資料做備份，以防萬一其他原因導緻資料無法再次恢複。使用dd指令或winhex工具将所有磁盤都鏡像成檔案。備份完部分資料如下圖：
三、故障分析
1、分析故障原因
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組的，是以需要根據上述分析的資訊将RAID組最新的狀态虛拟出來。然後分析LUN在RAID組中的配置設定情況，以及LUN配置設定的資料塊MAP。由于底層有6個LUN，是以隻需要将每一個LUN的資料塊分布MAP提取出來。然後針對這些資訊編寫相應的程式，對所有LUN的資料MAP做解析，然後根據資料MAP并導出所有LUN的資料。
四、LVM邏輯卷及VXFS檔案系統修複
1、解析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卷都解釋出來，但發現解釋程式出錯。
2、修複LVM邏輯卷
仔細分析程式報錯的原因，安排開發工程師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、恢複所有使用者檔案
在HP-Unix機器上mount檔案系統後，将所有使用者資料均備份至指定磁盤空間。所有使用者資料大小在1.2TB左右。部分檔案目錄截圖如下：
2、檢測資料庫檔案是否完整
使用Oracle資料庫檔案檢測工具“dbv”檢測每個資料庫檔案是否完整，發現并沒有錯誤。再使用北亞自主研發的Oracle資料庫檢測工具（檢驗更嚴格），發現有部分資料庫檔案和日志檔案校驗不一緻，安排進階資料庫工程師對此類檔案進行修複，并在次校驗，直到所有檔案校驗均完全通過。
3、啟動Oracle資料庫
由于我們提供的HP-Unix環境沒有此版本的Oracle資料，是以和使用者協調将原始生成環境帶至北亞資料恢複中心，然後将恢複的Oracle資料庫附加到原始生産環境的HP-Unix伺服器中，嘗試啟動Oracle資料庫，Oracle資料庫啟動成功。部分截圖如下：
六、資料驗證
由使用者方配合，啟動Oracle資料庫，啟動OA服務端，在本地筆記本安裝OA用戶端。通過OA用戶端對最新的資料記錄以及曆史資料記錄進行驗證，并且有使用者安排遠端不同部門人員進行遠端驗證。最終資料驗證無誤，資料完整，資料恢複成功。
七、資料恢複結論
由于故障發生後儲存現場環境良好，沒用做相關危險的操作，對後期的資料恢複有很大的幫助。整個資料恢複過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間内完成整個資料恢複，恢複的資料使用者方也相當滿意，Oracle資料庫服務，OA服務端等所有服務能夠正常啟動。
本文轉自 宋國建 51CTO部落格，原文連結：http://blog.51cto.com/sun510/1889709，如需轉載請自行聯系原作者