【基本信息】
服務器型號:IBM X3850服務器,
硬盤型號:73G SAS硬盤,
硬盤數量:5塊硬盤 其中4塊組成一個RAID5,另外一塊作爲熱備盤(Hot-Spare),
操做系統:linux redhat 5.3,應用系統爲構架於oracle的一個oa。node
【故障表現】
3號盤早已經離線,但熱備盤未自動激活rebuild(緣由不明),以後2號盤離線,RAID崩潰。
oracle已經再也不對本oa系統提供後續支持,用戶要求儘量數據恢復+操做系統復原。linux
【初檢結論】
熱備盤徹底無啓用,硬盤無明顯物理故障,無明顯同步表現。數據一般可恢復。數據庫
【恢復方案】
一、保護原環境,關閉服務器,確保在恢復過程當中再也不開啓服務器。
二、把故障硬盤編號排序,用以確保硬盤取出槽位後能夠徹底復原。
三、將故障硬盤掛載至只讀環境,對全部故障硬盤作徹底鏡像(參考<如何對磁盤作完整的全盤鏡像備份>)。備份完成後交回原故障盤,以後的恢復操做直到數據確認無誤前再也不涉及原故障盤。
四、對備份盤進行RAID結構分析,獲得其原來的RAID級別,條帶規則,條帶大小,校驗方向,META區域等。
五、根據獲得的RAID信息搭建一組虛擬的RAID5環境。
六、進行虛擬磁盤及文件系統解釋。
七、檢測虛擬結構是否正確,如不正確,重複4-7過程。
八、肯定數據無誤後,按用戶要求回遷數據。若是仍然使用原盤,需肯定已經徹底對原盤作過備份後,重建RAID,再作回遷。回遷操做系統時,可使用linux livecd或win pe(一般不支持)等進行,也能夠在故障服務器上用另外硬盤安裝一個回遷用的操做系統,再進行扇區級別的回遷。
九、數據移交後,由我數據恢復中心延長保管數據3天,以免可能忽略的紕漏。安全
【預估週期】
備份時間:2小時左右
解釋及導出數據時間:約4小時
回遷操做系統:約4小時。服務器
【過程詳解】
一、對原硬盤進行完整鏡像,鏡像後發現2號盤有10-20個壞扇區,其他磁盤均無壞道。
二、經過對結構的分析獲得的最佳結構爲0,1,2,3盤序,缺3號盤,塊大小512扇區,backward parity(Adaptec),結構以下圖:
三、組好後數據驗證,200M以上的最新壓縮包解壓無報錯,肯定結構正確。
四、直接按此結構生成虛擬RAID到一塊單硬盤上,打開文件系統無明顯報錯。
五、肯定備份包安全的狀況下,經客戶贊成後,對原盤重建RAID,重建時已經用全新硬盤更換損壞的2號盤。將恢復好的單盤用USB方式接入故障服務器,再用linux SystemRescueCd啓動故障服務器,以後經過dd命令進行全盤迴寫。
六、回寫後,啓動操做系統。
七、dd全部數據後,啓動操做系統,沒法進入,報錯信息爲:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied,分析爲此文件權限有問題。
八、用SystemRescueCd重啓後檢查,此文件時間、權限、大小均有明顯錯誤,顯然節點損壞。
九、從新分析重組數據中的根分區,定位出錯的/sbin/pidof,發現問題因2號盤壞道引發。
十、使用0,1,3這3塊盤,針對2號盤的損壞區域進行xor補齊。補齊後從新校驗文件系統,依然有錯誤,再次檢查inode表,發現2號盤損壞區域有部分節點表現爲(圖中的55 55 55部分):
十一、很明顯,雖然節點中描述的uid還正常存在,但屬性,大小,以最初的分配塊所有是錯誤的。按照全部可能進行分析,肯定無任何辦法找回此損壞節點。只能但願修復此節點,或複製一個相同的文件過來。對全部可能有錯的文件,均經過日誌肯定原節點塊的節點信息,再作修正。
十二、修正後從新dd根分區,執行fsck -fn /dev/sda5,進行檢測,依然有報錯,以下圖:
1三、根據提示,在系統中發現有多個節點共用一樣的數據塊。按此提示進行底層分析,發現,因3號盤早掉線,幫存在節點信息的新舊交集。
1四、按節點所屬的文件進行區別,清除錯誤節點後,再次執行fsck -fn /dev/sda5,依然有報錯信息,但已經不多。根據提示,發現這些節點多位於doc目錄下,不影響系統啓動,因而直接fsck -fy /dev/sda5強行修復。
1五、修復後,重啓系統,成功進入桌面。啓動數據庫服務,啓動應用軟件,一切正常,無報錯。oracle
到此,數據恢復及系統回遷工做完成。