【伺服器資料恢復】硬碟離線但是熱備盤未啟用導致RAID5崩潰的資料恢復案例

伺服器資料恢復環境：

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資訊，如下圖：

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部分)：

很明顯，雖然節點中描述的uid還正常存在，但屬性、大小、最初的分配塊全部是錯誤的。確定無法找回此損壞節點後只能

修復此節點，或複製一個相同的檔案過來。

10、對所有可能有錯的檔案透過日誌確定原節點塊的節點資訊，然後由北亞資料恢復工程師修正。

11、修正後重新dd根分割槽，執行fsck -fn /dev/sda5命令進行檢測，依然報錯，如下圖：

12、根據報錯提示，在系統中發現有多個節點共用同樣的資料塊。透過底層分析發現存在節點資訊的新舊交集問題。

13、按節點所屬的檔案進行區別，清除錯誤節點後執行fsck -fn /dev/sda5，依然有報錯但已經很少。根據錯誤提示發現這

些節點多位於doc目錄下，不影響系統啟動，於是直接使用fsck -fy /dev/sda5命令強行修復。修復後重啟系統，成功進入系

統桌面。

14、啟動oracle資料庫服務和OA應用軟體，一切正常無報錯。

15、讓使用者親自對恢復出來的資料和作業系統進行檢測，確定沒有問題，本次資料恢復工作完成。