一、故障描述

　　1、設備清單

設備名稱	設備型號	數量
HP FC存儲	HP MSA2000	1
450G SAS.硬盤		8

?

　　2、故障描述

　　整個存儲空間由8塊450GB SAS的硬盤組成，其中7塊硬盤組成一個RAID5的陣列，剩余1塊做成熱備盤使用。由于RAID5陣列中出現2塊硬盤損壞，而此時只有一塊熱備盤成功激活，因此導致RAID5陣列癱瘓，上層LUN無法正常使用。

　　二、檢測磁盤

　　由于存儲是因為RAID陣列中某些磁盤掉線，從而導致整個存儲不可用。因此接收到磁盤后先對所有磁盤做物理檢測，檢測完后發現沒有物理故障。接著使用壞道檢測工具檢測磁盤壞道，發現也沒有壞道。磁盤壞道檢測日志如下圖：

?

　　三、備份數據

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

?

　　四、故障分析

　　1、分析故障原因

　　由于前兩個步驟并沒有檢測到磁盤有物理故障或者是壞道，由此推斷可能是由于某些磁盤讀寫不穩定導致故障發生。因為HP MSA2000控制器檢查磁盤的策略很嚴格，一旦某些磁盤性能不穩定，HP MSA2000控制器就認為是壞盤，就將認為是壞盤的磁盤踢出RAID組。而一旦RAID組中掉線的盤到達到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組的，因此需要根據上述分析的信息將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信息是否會因存儲癱瘓導致LVM邏輯卷的信息損壞。經過仔細檢測，發現確實因為存儲癱瘓導致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客戶端對最新的數據記錄以及歷史數據記錄進行驗證，并且有用戶安排遠程不同部門人員進行遠程驗證。最終數據驗證無誤，數據完整，數據恢復成功。

　　八、移交數據

　　用戶方重新購買了8塊HP-MSA2000原廠硬盤，由北亞工程師配合重新對HP-MSA2000存儲進行配置。創建和原始一樣的Volume，并將恢復的數據全部復制到重新配置好的存儲中，并驗證所有服務能夠正常啟動，包括Oracle數據庫服務，OA服務端等。

　　九、數據恢復結論

　　由于故障發生后保存現場環境良好，沒做相關危險的操作，對后期的數據恢復有很大的幫助。整個數據恢復過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間內完成整個數據恢復，恢復的數據用戶方也相當滿意。

　　十、項目成員列表

工程師	姓名	電話	郵箱
商務	張曉娜	185，1528，3863	zxn#frombyte.com
項目主管	鄧奇	185，1528，3878	dq#frombyte.com
存儲工程師	鄧奇	185，1528，3878	dq#frombyte.com
RAID工程	宋國建	185，1528，3861	songguojian#frombyte.com
開發工程師	秦穎吉	185，1528，3871	qyj#frombyte.com
文件系統工程師	宋國建	185，1528，3861	songguojian#frombyte.com
審核工程師	張宇

　　工程師職能：

　　商務工程師：負責反饋消息給用戶

　　初檢工程師：負責設備初檢事宜

　　實施工程師：負責設備數據安全救援事宜

　　審核工程師：負責每一步流程審核

?

總結

以上是生活随笔為你收集整理的某公司数据恢复报告书的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。