服務器數據恢複環境：

8塊SAS硬盤中的7塊硬盤組成RAID5陣列，1塊作為熱備盤。

服務器故障：

故障服務器存儲中的RAID5陣列有2塊硬盤損壞離線，RAID5陣列癱瘓，影響上層LUN無法正常使用。管理員聯系我們數據恢複中心進行數據恢複，硬件工程師檢測硬盤沒有發現物理故障和壞道。

服務器數據恢複過程：

1、備份數據。使用數據恢複工具将所有磁盤鏡像備份。

北亞數據恢複——VXFS文件系統數據恢複

2、分析RAID結構。

故障服務器的LUN都是基于RAID的，需要先分析底層RAID的信息，再依據分析獲取到的raid相關信息重構原始RAID。通過分析獲知4号盤為hot Spare盤。分析Oracle數據庫頁在每個磁盤中的分布情況得出RAID組的條帶大小，磁盤順序及數據走向等RAID組的重要信息。

3、分析RAID掉線盤。

利用分析獲取到的RAID信息，通過北亞自主開發的RAID虛拟程序将原始的RAID拟出來。仔細分析每一塊硬盤中的數據，通過北亞自主開發的RAID校驗程序對條帶做校驗，将最先掉線的硬盤剔除出raid。

4、分析RAID組中的LUN信息。

将RAID最新的狀态虛拟出來以後分析LUN在RAID中的分配情況和LUN分配的數據塊MAP。隻需要将底層6個LUN的數據塊分布MAP提取出來，然後針對這些信息編寫相應的程序對所有LUN的數據MAP做解析，根據數據MAP導出所有LUN的數據。

北亞數據恢複——VXFS文件系統數據恢複

5、解析LVM邏輯卷。

分析生成出來的所有LUN，發現所有LUN中均包含HP-Unix的LVM邏輯卷信息。嘗試解析每個LUN中的LVM信息，發現一共有三套LVM：其中一套LVM中劃分了一個LV，存放OA服務器端的數據，另外一套LVM中劃分了一個LV，存放臨時備份數據

。其他4個LUN組成一套LVM并劃分了一個LV，存放Oracle數據庫文件。北亞數據恢複工程師編寫解釋LVM的程序嘗試将每套LVM中的LV卷解釋出來，但解釋程序出錯。

6、修複LVM邏輯卷。

仔細分析報錯的原因，由開發工程師debug程序出錯的位置并由高級文件系統工程師檢測恢複出來的LUN，檢測存儲癱瘓是否導緻LMV邏輯卷的信息損壞。經過仔細檢測，發現存儲癱瘓确實導緻了LVM信息損壞。嘗試人工對損壞的區域進行修複，并修改LVM解釋程序重新解析LVM邏輯卷。

7、解析VXFS文件系統。

搭建HP-Unix環境并将解釋出來的LV卷映射到HP-Unix，嘗試Mount文件系統。結果Mount文件系統出錯，嘗試使用“fsck –F vxfs” 命令修複vxfs文件系統，修複完成後還是不能挂載，懷疑底層vxfs文件系統的部分元數據被破壞，需要進行手工修複。

8、修複VXFS文件系統。

仔細分析解析出來的LV，并根據VXFS文件系統的底層結構校驗此文件系統是否完整。經過分析發現底層VXFS文件系統有問題，原因是存儲癱瘓的時候文件系統正在執行IO操作，因此部分文件系統元文件沒有更新導緻損壞。對這些損壞的元文件進行手工修複讓VXFS文件系統能夠正常解析。再次将修複好的LV卷挂載到HP-Unix小機上，嘗試Mount文件系統沒有報錯，成功挂載。

9、恢複所有用戶文件。

在HP-Unix機器上mount文件系統後将所有用戶數據均備份至指定磁盤空間。部分文件目錄截圖如下：

北亞數據恢複——VXFS文件系統數據恢複

10、檢測數據庫文件是否完整。

使用Oracle數據庫文件檢測工具“dbv”檢測每個數據庫文件是否完整，沒有發現錯誤。使用北亞自主研發的Oracle數據庫檢測工具檢測發現有部分數據庫文件和日志文件校驗不一緻，數據庫工程師對此類文件進行修複并再次校驗，直到所有文件校驗完全通過。

11、啟動Oracle數據庫。

由于我們數據恢複中心提供的HP-Unix環境沒有此版本的Oracle數據庫，和用戶協調将原始環境帶至北亞數據恢複中心，然後将恢複出來的Oracle數據庫附加到原始生産環境的HP-Unix服務器中并嘗試啟動Oracle數據庫，啟動成功。部分截圖如下：

北亞數據恢複——VXFS文件系統數據恢複

12、數據驗證。

由用戶方配合啟動Oracle數據庫，啟動OA服務端，在本地電腦端安裝OA客戶端。通過OA客戶端對最新的數據記錄以及曆史數據記錄進行驗證，并且安排不同部門人員進行遠程驗證。最終數據驗證無誤，數據完整，數據恢複成功。

數據恢複結論：

由于故障發生後保存現場環境良好，沒有做相關危險的操作，對後期的數據恢複有很大的幫助。整個數據恢複過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間内完成整個數據恢複，恢複的數據用戶方也相當滿意，Oracle數據庫服務，OA服務端等所有服務能夠正常啟動。