【raid資料恢復故障描述】

    需要進行資料恢復的是北京一家公司的IBM X3850伺服器，伺服器掛載了5塊73G SAS硬碟組成raid5磁碟陣列，4號盤為熱備盤(Hot-Spare)，由於未知原因2號盤離線後未能成功啟用熱備盤rebuild，後3號盤離線，RAID崩潰。
    使用者伺服器的作業系統為linux redhat 5.3,伺服器儲存有oracle資料庫，因oracle已經不再對基於資料庫上的oa系統提供後續支援，使用者要求儘可能資料恢復+作業系統復原。

【資料恢復初檢結情況】

    Raid陣列中硬碟無明顯物理故障，raid無同步表現。

【raid陣列資料恢復方案】

    1、關閉伺服器並確保資料恢復過程中保持伺服器關閉狀態以保護故障伺服器原始狀態。
    2、將故障硬碟標好序號，確保在拿出槽位後可以完全復原。
    3、將需要進行資料恢復的硬碟掛載至北亞資料恢復中心只讀環境中，對所有故障硬碟做完全映象(參考<如何對磁碟做完整的全盤映象備份>)。用於資料恢復操作使用。
    4、分析備份磁碟的raid結構，得到原raid陣列的RAID級別，條帶規則，條帶大小，校驗方向，META區域等必要資訊並根據這些資訊搭建虛擬raid5環境。
    5、解釋虛擬磁碟及檔案系統，然後檢測虛擬結構的正確性，如果虛擬結構不正確則重複上述步驟，直到成功為止。
    6、資料檢測正常後進行資料回遷，原則上不再使用原盤，如確實經客戶認可需要使用原盤則需要確認原盤已經完整備份後再重建raid、回遷資料。可以使用linux livecd或win pe(通常不支援)等進行，也可以在故障伺服器上用另外硬碟安裝一個回遷用的作業系統，再進行扇區級別的回遷。

【恢復週期】

    備份時間，約2小時。
    解釋及匯出資料時間，約4小時。
    回遷作業系統，約4小時。

【資料恢復實施過程】

    1、對使用者伺服器進行映象後發現除2號盤有壞扇區存在，其他盤均無壞道，壞道數量悅遊20個左右。
    2、分析結構：得到的最佳結構為0,1,2,3盤序，缺3號盤，塊大小512扇區，backward parity(Adaptec)，結構如下圖：
圖一：

    3、組好後資料驗證，200M以上的最新壓縮包進行測試性解壓檢視有無報錯，確定結構是否正確，解壓正常，結構正確。直接按此結構生成虛擬RAID到一塊單硬碟上，開啟檔案系統無明顯報錯。
    4、在對客戶原盤進行備份後重建raid陣列（將存在壞道的2號硬碟以新盤替換），連線恢復好的資料盤後通過“dd”命令進行全盤迴寫操作。
    5、通常情況下資料回寫後資料恢復工作完成，資料恢復為成功，但是在這一步出現了小故障，影響了資料恢復程序。
 

【系統復原過程】

    使用“dd”命令進行全盤迴寫操作後啟動作業系統卻出現報錯：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied ，系統無法進入
    工程師預判報錯原因為檔案許可權問題，於是用SystemRescueCd重啟後檢查檔案時間、許可權、大小均有明顯錯誤。
    對資料中的根分割槽進行了重新分析，將出錯的/sbin/pidof定位出來發現問題的原因再於2號盤的壞道。。
    通過沒有壞道的0號盤，1號盤，3號盤進行對2號盤的損壞區域xor補齊後校驗檔案系統依然有錯誤，再一次對iNode表進行檢查發現2號盤損壞區域有部分節點表現為(圖中的55 55 55部分)：
圖二：

    問題顯而易見，節點中描述的uid還正常存在，但屬性，大小，以最初的分配塊均不正確。此種情況下是沒有辦法找回損壞的節點了，只能希望修復此節點，或複製一個相同的檔案過來。對所有可能有錯的檔案，均通過日誌確定原節點塊的節點資訊，再做修正。
    修正後重新dd根分割槽，執行fsck -fn /dev/sda5，進行檢測，依然有報錯，如下圖：
圖三：

    根據提示，在系統中發現有多個節點共用同樣的資料塊。按此提示進行底層分析，發現，因3號盤早掉線，幫存在節點資訊的新舊交集。
    按節點所屬的檔案進行區別，清除錯誤節點後，再次執行fsck -fn /dev/sda5,依然有報錯資訊，但已經很少。根據提示，發現這些節點多位於doc目錄下，不影響系統啟動，於是直接fsck -fy /dev/sda5強行修復。
    修復後，重啟系統，成功進入桌面。
    啟動資料庫服務，啟動應用軟體，一切正常，無報錯。
    到此，資料恢復及系統回遷工作完成。