您好,登錄后才能下訂單哦!
【故障描述】
某公司的一臺服務器組了一個raid5磁盤陣列有兩塊磁盤先后掉線,服務器崩潰。故障服務器的操作系統為linux redhat 5.3,應用系統為構架于oracle的一個oa,數據重要,時間很急。因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),結構如下圖:
3、組好后數據驗證,200M以上的最新壓縮包解壓無報錯,確定結構正確。
4、直接按此結構生成虛擬RAID到一塊單硬盤上,打開文件系統無明顯報錯。
5、確定備份包安全的情況下,經客戶同意后,對原盤重建RAID,重建時已經用全新硬盤更換損壞的2號盤。將恢復好的單盤用USB方式接入故障服務器,再用linux SystemRescueCd啟動故障服務器,之后通過dd命令進行全盤回寫。
6、回寫后,啟動操作系統。正常情況下,這時候所有工作應該完成了。不巧的是,因幫頗費周折才解決,特意另起一段敘述。
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,進行檢測,依然有報錯,如下圖:
根據提示,在系統中發現有多個節點共用同樣的數據塊。按此提示進行底層分析,發現,因3號盤早掉線,幫存在節點信息的新舊交集。
按節點所屬的文件進行區別,清除錯誤節點后,再次執行fsck -fn /dev/sda5,依然有報錯信息,但已經很少。根據提示,發現這些節點多位于doc目錄下,不影響系統啟動,于是直接fsck -fy /dev/sda5強行修復。
修復后,重啟系統,成功進入桌面。
啟動數據庫服務,啟動應用軟件,一切正常,無報錯。
到此,數據恢復及系統回遷工作完成。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。