服務器數據恢復環境：

IBM某型號服務器，5個SAS硬盤組建RAID5(4個數據盤，1個熱備盤);

linux redhat操作系統;

上層應用為oa，數據庫為oracle;oracle已經不對本案例中的oa提供后續支持。

服務器故障&初檢&恢復方案：

RAID5中有一塊盤離線，但熱備盤由于未知原因未被激活rebuild，直到另外一塊盤離線導致RAID崩潰。用戶聯系我們數據恢復中心要求恢復數據和操作系統。

經過數據恢復工程師檢測，發現熱備盤完全沒有啟用，沒有發現有物理故障，也沒有同步的表現。

經過北亞數據恢復工程師團隊會診，確定最終的數據恢復方案：

1、關閉服務器，將硬盤標好序號取出。

2、將硬盤掛載到只讀環境對所有硬盤做鏡像備份。后續的數據恢復操作都在鏡像文件上進行，避免對原始數據造成二次破壞。

3、基于鏡像文件分析故障RAID5的結構，獲取RAID級別、條帶規則、條帶大小、校驗方向、META區域等RAID信息。

4、根據獲取到的RAID信息搭建虛擬的RAID5環境。

5、解釋虛擬磁盤及文件系統。

6、檢測虛擬結構是否正確，如不正確，重復3-5步驟。

7、最終確定數據沒有問題后按照用戶要求回遷數據。如果仍然使用原盤，需確定已經完全對原盤做過備份之后再重建RAID，然后做回遷。可以使用linux livecd回遷操作系統，也可以在故障服務器上用另外的硬盤安裝一個回遷用的操作系統，再進行扇區級別的回遷。

服務器數據恢復過程：

1、對故障服務器中所有硬盤進行完整鏡像，鏡像過程中發現后掉線的那個硬盤有10-20個壞扇區，其余磁盤均沒有發現壞道。

2、分析RAID得到RAID最佳結構、塊大小、校驗方向等RAID信息，如下圖：

北亞數據恢復——RAID5數據恢復

3、根據第2步獲取到的信息虛擬重建RAID后進行數據驗證，200M以上的壓縮包解壓無報錯，確定結構正確。

4、直接按此結構生成虛擬RAID到一塊單硬盤上，打開文件系統無明顯報錯。

5、確定備份包安全的前提下經用戶同意后利用原盤重建RAID，重建時已經用全新硬盤更換那塊后掉線的已經損壞的硬盤。將恢復好的單盤用USB方式接入故障服務器，用linux SystemRescueCd啟動故障服務器。

6、通過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、啟動oracle數據庫服務和OA應用軟件，一切正常無報錯。

15、讓用戶親自對恢復出來的數據和操作系統進行檢測，確定沒有問題，本次數據恢復工作完成。

審核編輯：湯梓紅