【伺服器資料恢復】raid5崩潰導致lvm資訊和VXFS檔案系統損壞的資料恢復案例

伺服器資料恢復環境：

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

伺服器故障：

故障伺服器儲存中的RAID5陣列有2塊硬碟損壞離線，RAID5陣列癱瘓，影響上層LUN無法正常使用。管理員聯絡我們資料

恢復中心進行資料恢復，硬體工程師檢測硬碟沒有發現物理故障和壞道。

伺服器資料恢復過程：

1、備份資料。使用資料恢復工具將所有磁碟映象備份。

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的資料。

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檔案系統後將所有使用者資料均備份至指定磁碟空間。部分檔案目錄截圖如下：

10、檢測資料庫檔案是否完整。

使用Oracle資料庫檔案檢測工具“dbv”檢測每個資料庫檔案是否完整，沒有發現錯誤。使用北亞自主研發的Oracle資料

庫檢測工具檢測發現有部分資料庫檔案和日誌檔案校驗不一致，資料庫工程師對此類檔案進行修復並再次校驗，直到所有

檔案校驗完全透過。

11、啟動Oracle資料庫。

由於我們資料恢復中心提供的HP-Unix環境沒有此版本的Oracle資料庫，和使用者協調將原始環境帶至北亞資料恢復中心，

然後將恢復出來的Oracle資料庫附加到原始生產環境的HP-Unix伺服器中並嘗試啟動Oracle資料庫，啟動成功。部分截

圖如下：

12、資料驗證。

由使用者方配合啟動Oracle資料庫，啟動OA服務端，在本地電腦端安裝OA客戶端。透過OA客戶端對最新的資料記錄以及

歷史資料記錄進行驗證，並且安排不同部門人員進行遠端驗證。最終資料驗證無誤，資料完整，資料恢復成功。

資料恢復結論：

由於故障發生後儲存現場環境良好，沒有做相關危險的操作，對後期的資料恢復有很大的幫助。整個資料恢復過程中雖

然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間內完成整個資料恢復，恢復的資料使用者方也相當滿意，Oracle

資料庫服務，OA服務端等所有服務能夠正常啟動。