1. 程式人生 > >【長文+圖片】HP FC MSA2000服務器癱瘓數據恢復過程

【長文+圖片】HP FC MSA2000服務器癱瘓數據恢復過程

掉線 成功 io操作 鏡像 執行 穩定 壞道 raid roc

服務器數據恢復故障描述

某公司的一臺HP FC MSA2000服務器,服務器中搭建RAID5陣列,服務器正常使用過程中出現2塊硬盤損壞並離線,而此時只有一塊熱備盤成功激活,因此導致RAID5陣列癱瘓,上層LUN無法正常使用,用戶聯系數據恢復中心進行服務器數據恢復。
由於服務器存儲是因為RAID陣列中某些磁盤掉線,從而導致整個存儲不可用。因此接收到磁盤以後先對所有磁盤做物理檢測,檢測完後發現沒有物理故障。接著使用壞道檢測工具檢測磁盤壞道,發現也沒有壞道。

服務器數據恢復過程:

1、備份服務器數據
考慮到數據的安全性以及可還原性,在做數據恢復之前需要對所有源數據做備份,以防萬一其他原因導致數據無法再次恢復。使用dd命令或winhex工具將所有磁盤都鏡像成文件。備份完部分數據如下圖:

圖一:技術分享圖片

2、分析服務器故障原因
由於前兩個步驟並沒有檢測到磁盤有物理故障或者是壞道,由此推斷可能是由於某些磁盤讀寫不穩定導致故障發生。因為HP MSA2000控制器檢查磁盤的策略很嚴格,一旦某些磁盤性能不穩定,HP MSA2000控制器就認為是壞盤,就將認為是壞盤的磁盤踢出RAID組。而一旦RAID組中掉線的盤到達到RAID級別允許掉盤的極限,那麽這個RAID組將變的不可用,上層基於RAID組的LUN也將變的不可用。目前初步了解的情況為基於RAID組的LUN有6個,均分配給HP-Unix小機使用,上層做的LVM邏輯卷,重要數據為Oracle數據庫及OA服務端。
3、分析服務器RAID組結構
HP MSA2000存儲的LUN都是基於RAID組的,因此需要先分析底層RAID組的信息,然後根據分析的信息重構原始的RAID組。分析每一塊數據盤,發現4號盤的數據同其它數據盤不太一樣,初步認為可能是hot Spare盤。接著分析其他數據盤,分析Oracle數據庫頁在每個磁盤中分布的情況,並根據數據分布的情況得出RAID組的條帶大小,磁盤順序及數據走向等RAID組的重要信息。

4、分析RAID組掉線盤
根據上述分析的RAID信息,嘗試通過北亞自主開發的RAID虛擬程序將原始的RAID組虛擬出來。但由於整個RAID組中一共掉線兩塊盤,因此需要分析這兩塊硬盤掉線的順序。仔細分析每一塊硬盤中的數據,發現有一塊硬盤在同一個條帶上的數據和其他硬盤明顯不一樣,因此初步判斷此硬盤可能是最先掉線的,通過北亞自主開發的RAID校驗程序對這個條帶做校驗,發現除掉剛才分析的那塊硬盤得出的數據是最好的,因此可以明確最先掉線的硬盤了。
5、分析RAID組中的LUN信息
由於LUN是基於RAID組的,因此需要根據上述分析的信息將RAID組最新的狀態虛擬出來。然後分析LUN在RAID組中的分配情況,以及LUN分配的數據塊MAP。由於底層有6個LUN,因此只需要將每一個LUN的數據塊分布MAP提取出來。然後針對這些信息編寫相應的程序,對所有LUN的數據MAP做解析,然後根據數據MAP並導出所有LUN的數據。
圖二:技術分享圖片

6、解析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卷都解釋出來,但發現解釋程序出錯。
7、修復LVM邏輯卷
仔細分析程序報錯的原因,安排開發工程師debug程序出錯的位置,並同時安排高級文件系統工程師對恢復的LUN做檢測,檢測LVM信息是否會因存儲癱瘓導致LMV邏輯卷的信息損壞。經過仔細檢測,發現確實因為存儲癱瘓導致LVM信息損壞。嘗試人工對損壞的區域進行修復,並同步修改程序,重新解析LVM邏輯卷。
8、解析VXFS文件系統
搭建HP-Unix環境,將解釋出來的LV卷映射到HP-Unix,並嘗試Mount文件系統。結果Mount文件系統出錯,嘗試使用“fsck –F vxfs” 命令修復vxfs文件系統,但修復結果還是不能掛載,懷疑底層vxfs文件系統的部分元數據可能破壞,需要進行手工修復。
9、修復VXFS文件系統
仔細分析解析出來的LV,並根據VXFS文件系統的底層結構校驗此文件系統是否完整。分析發現底層VXFS文件系統果然有問題,原來當時存儲癱瘓的同時此文件在系統正在執行IO操作,因此導致部分文件系統元文件沒有更新以及損壞。人工對這些損壞的元文件進行手工修復,保證VXFS文件系統能夠正常解析。再次將修復好的LV卷掛載到HP-Unix小機上,嘗試Mount文件系統,文件系統沒有報錯,成功掛載。
10、恢復所有用戶文件
在HP-Unix機器上mount文件系統後,將所有用戶數據均備份至指定磁盤空間。所有用戶數據大小在1.2TB左右。部分文件目錄截圖如下:
圖三:技術分享圖片

11、檢測數據庫文件是否完整
使用Oracle數據庫文件檢測工具“dbv”檢測每個數據庫文件是否完整,發現並沒有錯誤。再使用北亞自主研發的Oracle數據庫檢測工具(檢驗更嚴格),發現有部分數據庫文件和日誌文件校驗不一致,安排高級數據庫工程師對此類文件進行修復,並在次校驗,直到所有文件校驗均完全通過。
12、啟動Oracle數據庫
由於我們提供的HP-Unix環境沒有此版本的Oracle數據,因此和用戶協調將原始生成環境帶至數據恢復中心,然後將恢復的Oracle數據庫附加到原始生產環境的HP-Unix服務器中,嘗試啟動Oracle數據庫,Oracle數據庫啟動成功。部分截圖如下:
圖四:技術分享圖片

13、服務器數據驗證
由用戶方配合,啟動Oracle數據庫,啟動OA服務端,在本地筆記本安裝OA客戶端。通過OA客戶端對最新的數據記錄以及歷史數據記錄進行驗證,並且有用戶安排遠程不同部門人員進行遠程驗證。最終數據驗證無誤,數據完整,數據恢復成功。
由於故障發生後保存現場環境良好,沒用做相關危險的操作,對後期的數據恢復有很大的幫助。整個數據恢復過程中雖然遇到好多技術瓶頸,但也都一一解決。最終在預期的時間內完成整個服務器數據恢復,恢復的數據用戶方也相當滿意,Oracle數據庫服務,OA服務端等所有服務能夠正常啟動。

【長文+圖片】HP FC MSA2000服務器癱瘓數據恢復過程