北亞針對伺服器RAID5硬碟故障進行資料恢複案例

【基本資訊】

伺服器型号：IBM X3850伺服器，

硬碟型号：73G SAS硬碟，

硬碟數量：5塊硬碟 其中4塊組成一個RAID5，另一塊做為熱備盤(Hot-Spare)，

作業系統：linux redhat 5.3,應用系統為構架于oracle的一個oa。

【故障表現】

    3号盤早已經離線，但熱備盤未自動激活rebuild（原因不明），之後2号盤離線，RAID崩潰。

    oracle已經不再對本oa系統提供後續支援，使用者要求盡可能資料恢複+作業系統複原。

【初檢結論】

    熱備盤完全無啟用，硬碟無明顯實體故障，無明顯同步表現。資料通常可恢複。

【恢複方案】

    1、保護原環境，關閉伺服器，確定在恢複過程中不再開啟伺服器。

    2、把故障硬碟編号排序，用以確定硬碟取出槽位後可以完全複原。

    3、将故障硬碟挂載至隻讀環境，對所有故障硬碟做完全鏡像(參考<如何對磁盤做完整的全盤鏡像備份>)。備份完成後交回原故障盤，之後的恢複操作直到資料确認無誤前不再涉及原故障盤。

    4、對備份盤進行RAID結構分析，得到其原來的RAID級别，條帶規則，條帶大小，校驗方向，META區域等。

    5、根據得到的RAID資訊搭建一組虛拟的RAID5環境。

    6、進行虛拟磁盤及檔案系統解釋。

    7、檢測虛拟結構是否正确，如不正确，重複4-7過程。

    8、确定資料無誤後，按使用者要求回遷資料。如果仍然使用原盤，需确定已經完全對原盤做過備份後，重建RAID，再做回遷。回遷作業系統時，可以使用linux livecd或win pe(通常不支援)等進行，也可以在故障伺服器上用另外硬碟安裝一個回遷用的作業系統，再進行扇區級别的回遷。

    9、資料移交後，由我資料恢複中心延長保管資料3天，以避免可能忽略的纰漏。

【預估周期】

    備份時間：2小時左右

    解釋及導出資料時間：約4小時

    回遷作業系統：約4小時。

【恢複費用】

    略。。。

【過程詳解】 

    1、對原硬碟進行完整鏡像，鏡像後發現2号盤有10-20個壞扇區，其餘磁盤均無壞道。

    2、通過對結構的分析得到的最佳結構為0,1,2,3盤序，缺3号盤，塊大小512扇區，backward parity(Adaptec)，結構如下圖：

圖一：

<a href="https://s3.51cto.com/oss/201711/08/2477a365322ce0e4af60e67de89514f1.jpg-wh_500x0-wm_3-wmp_4-s_2211577146.jpg" target="_blank"></a>

    3、組好後資料驗證，200M以上的最新壓縮包解壓無報錯，确定結構正确。

    4、直接按此結構生成虛拟RAID到一塊單硬碟上，打開檔案系統無明顯報錯。

    5、确定備份包安全的情況下，經客戶同意後，對原盤重建RAID，重建時已經用全新硬碟更換損壞的2号盤。将恢複好的單盤用USB方式接入故障伺服器，再用linux SystemRescueCd啟動故障伺服器，之後通過dd指令進行全盤回寫。

    6、回寫後，啟動作業系統。

    7、dd所有資料後，啟動作業系統，無法進入，報錯資訊為：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied，分析為此檔案權限有問題。

    8、用SystemRescueCd重新開機後檢查，此檔案時間、權限、大小均有明顯錯誤，顯然節點損壞。

    9、重新分析重組資料中的根分區，定位出錯的/sbin/pidof，發現問題因2号盤壞道引起。

    10、使用0，1，3這3塊盤，針對2号盤的損壞區域進行xor補齊。補齊後重新校驗檔案系統，依然有錯誤，再次檢查inode表，發現2号盤損壞區域有部分節點表現為(圖中的55 55 55部分)：

圖二：

<a href="https://s2.51cto.com/oss/201711/08/6285f365834e3e8792165c5a7b10184a.png-wh_500x0-wm_3-wmp_4-s_3844411395.png" target="_blank"></a>

    11、很明顯，雖然節點中描述的uid還正常存在，但屬性，大小，以最初的配置設定塊全部是錯誤的。按照所有可能進行分析，确定無任何辦法找回此損壞節點。隻能希望修複此節點，或複制一個相同的檔案過來。對所有可能有錯的檔案，均通過日志确定原節點塊的節點資訊，再做修正。

    12、修正後重新dd根分區，執行fsck -fn /dev/sda5，進行檢測，依然有報錯，如下圖：

圖三：

<a href="https://s1.51cto.com/oss/201711/08/c12d895d84939dc71f62ff85a49ac6f6.jpg-wh_500x0-wm_3-wmp_4-s_3741180659.jpg" target="_blank"></a>

    13、根據提示，在系統中發現有多個節點共用同樣的資料塊。按此提示進行底層分析，發現，因3号盤早掉線，幫存在節點資訊的新舊交集。

    14、按節點所屬的檔案進行差別，清除錯誤節點後，再次執行fsck -fn /dev/sda5,依然有報錯資訊，但已經很少。根據提示，發現這些節點多位于doc目錄下，不影響系統啟動，于是直接fsck -fy /dev/sda5強行修複。

    15、修複後，重新開機系統，成功進入桌面。啟動資料庫服務，啟動應用軟體，一切正常，無報錯。

    到此，資料恢複及系統回遷工作完成。

本文轉自 宋國建 51CTO部落格，原文連結：http://blog.51cto.com/sun510/1979995，如需轉載請自行聯系原作者