服務器數據恢復環境:
某公司一臺服務器中組建一組raid5磁盤陣列;
上層操作系統為linux redhat,部署OA系統,后端數據庫為oracle。
服務器故障&初檢:
raid5中有2塊磁盤先后掉線,服務器崩潰。oracle已經不對該OA系統提供后續技術支持,用戶方要求恢復數據和操作系統。
經過初步檢測,發現熱備盤沒有啟用,硬盤無明顯的物理故障和同步表現。
服務器數據恢復過程:
1、將故障服務器中所有硬盤做好標記,取出后掛載至只讀環境,對所有硬盤以只讀方式做完全鏡像備份,鏡像過程中發現有一塊磁盤(2號盤)有少量壞扇區,其他磁盤均沒有發現壞道。鏡像完成后將硬盤按照編號復原至原服務器,之后的數據分析和數據恢復操作都基于鏡像文件進行,避免對原始數據造成二次破壞。
2、基于鏡像文件分析RAID結構,獲取到原RAID級別,條帶規則,條帶大小,校驗方向,META區域等RAID相關信息。分析結構:得到的最佳結構為0,1,2,3盤序,缺3號盤,塊大小512扇區,backward parity(Adaptec)。
raid結構:
北亞企安數據恢復——raid5數據恢復
3、檢測虛擬重構的RAID結構是否正確,經過檢測發現200M以上的最新壓縮包解壓無報錯,確定結構正確。直接按此結構生成虛擬RAID到一塊單硬盤上,打開文件系統無明顯報錯。
4、確定備份包安全的前提下,經用戶方同意后,北亞企安數據恢復工程師用全新硬盤更換損壞的2號盤,然后對原盤重建RAID。將恢復好的單盤用USB方式接入故障服務器,再用linux SystemRescueCd啟動故障服務器,之后通過dd命令進行全盤回寫。
5、完成回寫后啟動操作系統,結果發現無法進入系統并報錯,報錯信息為:“/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied”。懷疑此文件權限有問題,用SystemRescueCd重啟后檢查發現此文件的時間,權限,大小均有明顯錯誤,顯然是節點損壞。
6、重新分析&重組數據中的根分區,定位出錯的/sbin/pidof,發現問題是由2號盤壞道導致的。
7、通過raid中的另外3塊盤對2號盤的損壞區域進行xor補齊。補齊后重新校驗文件系統,依然有錯誤,再次檢查inode表,發現2號盤損壞區域有部分節點表現為下圖中的55 55 55部分。
北亞企安數據恢復——raid5數據恢復
8、很明顯,雖然節點中描述的uid還正常存在,但屬性,大小和最初的分配塊全部都是錯誤的。按照所有的可能進行分析后,確實沒有任何辦法能找回此損壞節點。只能嘗試修復此節點或復制一個相同的文件過來。
9、北亞企安數據恢復工程師對所有可能有錯誤的文件通過日志確定原節點塊的節點信息并做修正。
10、修正后重新dd根分區,執行fsck -fn /dev/sda5進行檢測,出現報錯:
北亞企安數據恢復——raid5數據恢復
報錯提示在系統中發現有多個節點共用同樣的數據塊。按此提示進行底層分析,發現因3號盤早掉線,存在節點信息的新舊交集。
11、按節點所屬的文件進行區別,清除錯誤節點后再次執行fsck -fn /dev/sda5進行檢測,依然有極少量的報錯信息。根據報錯信息的提示,發現這些節點多位于doc目錄下,不影響系統的啟動,于是直接執行fsck -fy /dev/sda5強行修復。
12、修復完成后重啟系統,成功進入系統桌面。啟動數據庫服務,啟動OA系統,一切正常,無報錯。
13、由用戶方工程師親自驗證,經過反復驗證,確認恢復結果有效。至此,本次數據恢復工作完成。
審核編輯黃宇
-
Linux
+關注
關注
87文章
11321瀏覽量
209856 -
服務器
+關注
關注
12文章
9234瀏覽量
85646 -
數據恢復
+關注
關注
10文章
581瀏覽量
17525 -
RAID5
+關注
關注
0文章
121瀏覽量
12738
發布評論請先 登錄
相關推薦
評論