【伺服器資料恢復】某品牌x3850伺服器RAID5資料恢復案例

北亞資料恢復發表於2022-06-14

伺服器故障:

某公司的一臺某品牌x3850伺服器raid5中兩塊磁碟先後掉線,伺服器崩潰。故障伺服器的作業系統為linux redhat,應用為

公司oa,資料庫採用oracle。因oracle已經不再對此oa提供後續支援,管理員聯絡我們資料恢復中心要求儘可能恢復資料和

系統。

資料恢復工程師對故障伺服器進行檢測,發現熱備盤沒有啟用,硬碟無明顯物理故障,無明顯同步表現。


伺服器資料恢復方案:

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

2、將故障硬碟標好序號,確保在拿出槽位後可以完全復原。

3、將故障硬碟掛載至只讀環境,對所有故障硬碟做完全映象(參考<如何對磁碟做完整的全盤映象備份>)。備份完成後交回

原故障盤,之後的恢復操作直到資料確認無誤前不再涉及原故障盤。

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

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

6、進行虛擬磁碟及檔案系統解釋。

7、檢測虛擬結構是否正確,如不正確,重複4-7過程。

8、確定資料無誤後,按使用者要求回遷資料。如果仍然使用原盤,需確定已經完全對原盤做過備份後,重建RAID,再做回遷

。回遷作業系統時,可以使用linux livecd或win pe(通常不支援)等進行,也可以在故障伺服器上用另外硬碟安裝一個回遷用

的作業系統,再進行扇區級別的回遷。

9、資料移交後,由北亞資料恢復中心延長保管資料3天,以避免可能忽略的紕漏。

 

伺服器資料恢復過程:

1、對故障伺服器中的所有硬碟進行完整映象,映象後資料恢復工程師發現2號盤有10-20個壞扇區,其餘磁碟沒有發現壞道。

2、分析結構:獲取到的最佳結構為0,1,2,3盤序,缺3號盤,塊大小為512扇區,backward parity(Adaptec),結構如下圖:



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

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

5、確定備份包安全的情況下,經管理員同意後,北亞資料恢復工程師對原盤重建RAID,重建時已經用全新硬碟更換損壞的

2號盤。將恢復好的單盤用USB方式接入故障伺服器,再用linux SystemRescueCd啟動故障伺服器,之後通過命令進行全盤

回寫。

6、回寫後,啟動作業系統。正常情況下,這時候所有工作應該完成了,不巧的是,問題還沒有解決。


下面是後續的資料恢復過程:


1、接前文:回寫完所有資料後,啟動作業系統報錯,報錯資訊為:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission 

denied。

2、根據錯誤資訊得知此檔案許可權有問題,用SystemRescueCd重啟後檢查,發現此檔案時間,許可權,大小均有明顯錯誤,

顯然節點損壞。

3、重新分析重組資料中的根分割槽,定位出錯的/sbin/pidof,發現問題產生原因是2號盤的壞道。

4、使用0,1,3這3塊盤,針對2號盤的損壞區域進行xor補齊。補齊後重新校驗檔案系統,依然有錯誤,再次檢查inode表,

發現2號盤損壞區域有部分節點表現為下圖中的55 55 55部分:



5、雖然節點中描述的uid還正常存在,但屬性,大小,最初的分配塊全部是錯誤的。按照所有可能進行分析,資料恢復工程

師確定無法找回此損壞節點,只能希望修復此節點,或複製一個相同的檔案過來。

6、對所有可能有錯的檔案通過日誌確定原節點塊的節點資訊,再做修正。

7、修正後重新dd根分割槽,執行fsck -fn /dev/sda5,進行檢測,依然有報錯,如下圖:



8、根據提示,在系統中發現有多個節點共用同樣的資料塊。按此提示進行底層分析,發現因3號盤早掉線,存在節點資訊的

新舊交集。

9、按節點所屬的檔案進行區別,清除錯誤節點後,再次執行fsck -fn /dev/sda5,依然有極少量的報錯資訊。根據提示,發

現這些節點多位於doc目錄下,不影響系統啟動,於是直接fsck -fy /dev/sda5強行修復。

10、修復後,重啟系統成功進入桌面。

11、啟動資料庫服務,啟動應用軟體,一切正常,無報錯。資料恢復及系統回遷工作完成。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2900433/,如需轉載,請註明出處,否則將追究法律責任。

相關文章