服務器raid5兩塊硬盤離線vxfs文件系統恢復數據方法
阿新 • • 發佈：2018-04-19
服務器 數據恢復 raid5 磁盤掉線 服務器數據恢復故障描述
客戶的服務器共有8塊450GB SAS硬盤，其中7塊硬盤組成一個RAID5陣列，1塊熱備盤。陣列中2塊硬盤損壞並離線，導致RAID5陣列癱瘓，進而影響上層LUN無法正常使用。硬盤無物理故障，無壞道。
對服務器raid數據恢復過程：
1、備份數據
使用dd命令或數據恢復工具將所有磁盤鏡像成文件。
圖一：
2、分析RAID組結構
服務器的LUN都是基於RAID組的，所以需要先對底層RAID組的信息作出分析，再依據這些數據重構原始的RAID組。通過分析得知4號盤為hot Spare盤。繼續分析Oracle數據庫頁在每個磁盤中分布的情況，進而得出RAID組的條帶大小，磁盤順序及數據走向等RAID組的重要信息。
根據上述分析的RAID信息，嘗試通過RAID虛擬程序將原始的RAID組虛擬出來。仔細分析每一塊硬盤中的數據，通過北亞自主開發的RAID校驗程序對這個條帶做校驗，將最先掉線的硬盤剔除出raid。
4、分析RAID組中的LUN信息
由於LUN是基於RAID組的，因此需要根據上述分析的信息將RAID組最新的狀態虛擬出來。然後分析LUN在RAID組中的分配情況，以及LUN分配的數據塊MAP。由於底層有6個LUN，因此只需要將每一個LUN的數據塊分布MAP提取出來。然後針對這些信息編寫相應的程序，對所有LUN的數據MAP做解析，然後根據數據MAP並導出所有LUN的數據。
圖二：
5、解析LVM邏輯卷
6、修復LVM邏輯卷
仔細分析程序報錯的原因，安排開發工程師debug程序出錯的位置，並同時安排高級文件系統工程師對恢復的LUN做檢測，檢測LVM信息是否會因存儲癱瘓導致LMV邏輯卷的信息損壞。經過仔細檢測，發現確實因為存儲癱瘓導致LVM信息損壞。嘗試人工對損壞的區域進行修復，並同步修改程序，重新解析LVM邏輯卷。
搭建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文件系統後，將所有用戶數據均備份至指定磁盤空間。所有用戶數據大小在1.2TB左右。部分文件目錄截圖如下：
圖三：
10、檢測數據庫文件是否完整
使用Oracle數據庫文件檢測工具“dbv”檢測每個數據庫文件是否完整，發現並沒有錯誤。再使用北亞自主研發的Oracle數據庫檢測工具（檢驗更嚴格），發現有部分數據庫文件和日誌文件校驗不一致，安排高級數據庫工程師對此類文件進行修復，並在次校驗，直到所有文件校驗均完全通過。
11、啟動Oracle數據庫
由於我們提供的HP-Unix環境沒有此版本的Oracle數據，因此和用戶協調將原始生成環境帶至北亞數據恢復中心，然後將恢復的Oracle數據庫附加到原始生產環境的HP-Unix服務器中，嘗試啟動Oracle數據庫，Oracle數據庫啟動成功。部分截圖如下：
圖四：
12、數據驗證
由用戶方配合，啟動Oracle數據庫，啟動OA服務端，在本地筆記本安裝OA客戶端。通過OA客戶端對最新的數據記錄以及歷史數據記錄進行驗證，並且有用戶安排遠程不同部門人員進行遠程驗證。最終數據驗證無誤，數據完整，數據恢復成功。
由於故障發生後保存現場環境良好，沒用做相關危險的操作，對後期的數據恢復有很大的幫助。整個數據恢復過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間內完成整個數據恢復，恢復的數據用戶方也相當滿意，Oracle數據庫服務，OA服務端等所有服務能夠正常啟動。
客戶的服務器共有8塊450GB SAS硬盤，其中7塊硬盤組成一個RAID5陣列，1塊熱備盤。陣列中2塊硬盤損壞並離線，導致RAID5陣列癱瘓，進而影響上層LUN無法正常使用。硬盤無物理故障，無壞道。
對服務器raid數據恢復過程：
1、備份數據
使用dd命令或數據恢復工具將所有磁盤鏡像成文件。
圖一：
2、分析RAID組結構
服務器的LUN都是基於RAID組的，所以需要先對底層RAID組的信息作出分析，再依據這些數據重構原始的RAID組。通過分析得知4號盤為hot Spare盤。繼續分析Oracle數據庫頁在每個磁盤中分布的情況，進而得出RAID組的條帶大小，磁盤順序及數據走向等RAID組的重要信息。
根據上述分析的RAID信息，嘗試通過RAID虛擬程序將原始的RAID組虛擬出來。仔細分析每一塊硬盤中的數據，通過北亞自主開發的RAID校驗程序對這個條帶做校驗，將最先掉線的硬盤剔除出raid。
4、分析RAID組中的LUN信息
由於LUN是基於RAID組的，因此需要根據上述分析的信息將RAID組最新的狀態虛擬出來。然後分析LUN在RAID組中的分配情況，以及LUN分配的數據塊MAP。由於底層有6個LUN，因此只需要將每一個LUN的數據塊分布MAP提取出來。然後針對這些信息編寫相應的程序，對所有LUN的數據MAP做解析，然後根據數據MAP並導出所有LUN的數據。
圖二：
5、解析LVM邏輯卷
6、修復LVM邏輯卷
仔細分析程序報錯的原因，安排開發工程師debug程序出錯的位置，並同時安排高級文件系統工程師對恢復的LUN做檢測，檢測LVM信息是否會因存儲癱瘓導致LMV邏輯卷的信息損壞。經過仔細檢測，發現確實因為存儲癱瘓導致LVM信息損壞。嘗試人工對損壞的區域進行修復，並同步修改程序，重新解析LVM邏輯卷。
搭建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文件系統後，將所有用戶數據均備份至指定磁盤空間。所有用戶數據大小在1.2TB左右。部分文件目錄截圖如下：
圖三：
10、檢測數據庫文件是否完整
使用Oracle數據庫文件檢測工具“dbv”檢測每個數據庫文件是否完整，發現並沒有錯誤。再使用北亞自主研發的Oracle數據庫檢測工具（檢驗更嚴格），發現有部分數據庫文件和日誌文件校驗不一致，安排高級數據庫工程師對此類文件進行修復，並在次校驗，直到所有文件校驗均完全通過。
11、啟動Oracle數據庫
由於我們提供的HP-Unix環境沒有此版本的Oracle數據，因此和用戶協調將原始生成環境帶至北亞數據恢復中心，然後將恢復的Oracle數據庫附加到原始生產環境的HP-Unix服務器中，嘗試啟動Oracle數據庫，Oracle數據庫啟動成功。部分截圖如下：
圖四：
12、數據驗證
由用戶方配合，啟動Oracle數據庫，啟動OA服務端，在本地筆記本安裝OA客戶端。通過OA客戶端對最新的數據記錄以及歷史數據記錄進行驗證，並且有用戶安排遠程不同部門人員進行遠程驗證。最終數據驗證無誤，數據完整，數據恢復成功。
由於故障發生後保存現場環境良好，沒用做相關危險的操作，對後期的數據恢復有很大的幫助。整個數據恢復過程中雖然遇到好多技術瓶頸，但也都一一解決。最終在預期的時間內完成整個數據恢復，恢復的數據用戶方也相當滿意，Oracle數據庫服務，OA服務端等所有服務能夠正常啟動。
服務器raid5兩塊硬盤離線vxfs文件系統恢復數據方法