服務器數據恢復環境：
某品牌X系列服務器，4塊SAS硬盤組建了一組RAID5陣列，還有1塊磁盤作為熱備盤使用。服務器上層安裝的linux操作系統，操作系統上部署了一個基于oracle數據庫的OA（oracle已經不再為該OA系統提供后續服務支持）。

服務器故障：
raid5中一塊磁盤離線，熱備盤未自動激活rebuild（原因不明）。服務器在運行一段時間后，另一塊磁盤離線，RAID5陣列崩潰。用戶方要求盡可能恢復服務器操作系統和服務器中的數據。
將故障服務器中所有磁盤編號后取出，硬件工程師檢測后沒有發現有磁盤（包括離線的2塊磁盤和熱備盤）存在明顯的物理故障。熱備盤完全沒有啟用，無明顯同步表現。

服務器數據恢復方案：
1、將所有磁盤以只讀方式進行扇區級的全盤鏡像，鏡像完成后將所有磁盤按照編號還原到原服務器中，后續的數據分析和數據恢復操作都基于鏡像文件進行，避免對原始磁盤數據造成二次破壞。
2、基于鏡像文件分析RAID5結構，獲取到RAID5條帶規則、條帶大小、校驗方向、META區域等raid結構相關信息。
3、根據獲取到的RAID結構信息虛擬重構RAID5。
4、解釋虛擬磁盤及文件系統。
5、檢測重構的raid5結構是否正確，如不正確，重復2-4過程。
6、檢測raid5結構沒有問題以及數據無誤后，按用戶要求回遷數據。

服務器數據恢復過程：
1、在對故障服務器中磁盤做鏡像時，發現后離線的那塊磁盤有十幾個壞扇區，其余磁盤沒有發現有壞道。
2、基于鏡像文件分析獲取raid5結構相關信息。

北亞企安數據恢復——Raid5數據恢復

3、根據獲取到的raid結構信息虛擬重組raid5，重組完成后驗證數據，發現200M以上的壓縮包解壓沒有報錯，由此可以確定分析出來的raid5結構正確。
4、按照該raid5結構生成虛擬RAID到一塊單硬盤上，打開文件系統沒有出現報錯。
5、確定備份包沒有問題和經過用戶方的同意后，用新硬盤更換存在壞扇區的那塊磁盤，然后對原盤重建RAID。
6、將恢復好的單盤用USB方式接入故障服務器，用linux SystemRescueCd啟動故障服務器，然后使用dd命令進行全盤回寫。
7、dd所有數據后，啟動操作系統，無法進入操作系統桌面并出現報錯，報錯信息為：“/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied”，北亞企安數據恢復工程師初步判斷此文件權限有問題。用SystemRescueCd重啟后檢查，發現此文件時間、權限、大小均有明顯錯誤，很顯然節點損壞。
8、重新分析重組數據中的根分區，定位出錯的/sbin/pidof/，發現出錯是由磁盤壞道導致的。
9、北亞企安數據恢復工程師使用3塊完好的磁盤對后離線、存在壞道的那塊磁盤的損壞區域進行xor補齊。補齊后重新校驗文件系統依然有錯誤。再次檢查inode表，發現后離線、存在壞道的磁盤的損壞區域有部分節點表現為(55 55 55部分)：

北亞企安數據恢復——Raid5數據恢復

很明顯，雖然節點中描述的uid正常存在，但屬性、大小、最初的分配塊全部是錯誤的。北亞企安數據恢復工程師按照所有可能性進行分析，確定無法找回此損壞節點。只能修復此節點或者復制一個相同的文件過來。
10、針對所有可能有錯的文件，通過日志確定原節點塊的節點信息，再做修正。
11、修正后重新dd根分區，執行fsck -fn /dev/sda5/進行檢測，依然報錯。

北亞企安數據恢復——Raid5數據恢復

12、根據報錯提示，在系統中發現有多個節點共用同樣的數據塊。按照提示分析底層，發現存在節點信息的新舊交集。
13、按節點所屬的文件進行區別，清除錯誤節點后，再次執行fsck -fn /dev/sda5進行檢測，依然有極少量的報錯信息。根據報錯提示，發現這些節點多位于doc目錄下，不影響系統啟動。直接執行fsck -fy /dev/sda5/強行修復。
14、修復完成后重啟系統，成功進入操作系統桌面。
15、啟動oracle數據庫服務，啟動應用軟件，一切正常，無報錯。
16、用戶方對操作系統，oracle數據庫以及OA數據進行檢測，經過多部門的反復檢測，確認恢復數據完整可用。本次數據恢復工作完成。

審核編輯 黃宇