服務器數據恢復環境:
某品牌服務器中有4塊SAS硬盤組建了一組RAID5陣列,另外1塊磁盤作為熱備盤使用。上層操作系統為redhat linux,部署了一個數據庫是oracle的OA。
服務器故障&初檢:
RAID5中一塊磁盤離線后熱備盤未自動激活rebuild,之后另外一塊磁盤離線,RAID5陣列崩潰。因為oracle已經不再對服務器中部署的oa提供后續支持,用戶聯系我們數據恢復中心要求恢復數據和復原操作系統。
將故障服務器中所有磁盤編號后取出,由硬件工程師對所有磁盤進行檢測。經過檢測發現熱備盤根本沒有啟用,不存在物理故障,無明顯同步表現。
服務器數據恢復&操作系統復原過程:
1、將故障服務器中所有磁盤以只讀方式做完整鏡像,鏡像過程中發現后離線的磁盤有十幾個壞扇區,其余磁盤均沒有發現有壞道。鏡像完成后將所有磁盤按照編號還原到原服務器中,后續的數據分析和數據恢復都基于鏡像文件進行,避免對原始磁盤數據造成二次破壞。
2、基于鏡像文件分析RAID5結構信息,獲取到盤序,塊大小,backward parity(Adaptec)等RAID相關信息。
北亞企安數據恢復——raid5數據恢復
3、根據上一步獲取到的RAID相關信息虛擬重組RAID并驗證數據,發現200M以上的壓縮包解壓無報錯,確定結構正確。
4、按照此RAID結構生成虛擬RAID到一塊單硬盤上,打開文件系統沒有發現明顯報錯。
5、得到用戶授權后在原盤重建RAID(重建時已經用全新硬盤更換發現壞道的后離線磁盤)。
6、將恢復好的單盤用USB方式接入故障服務器,用linux SystemRescueCd啟動故障服務器,然后使用dd命令全盤回寫。
7、回寫完成后啟動操作系統,但是無法進入系統,報錯信息為:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。
8、懷疑此文件權限有問題,用SystemRescueCd重啟后檢查,此文件時間,權限,大小均有明顯錯誤,顯然是節點損壞導致的錯誤。
9、重新分析重組數據中的根分區,定位出錯的/sbin/pidof,發現錯誤是由后離線的那塊磁盤上的壞道所引起。
10、使用完好的3塊盤對后離線的那塊盤的損壞區域進行xor補齊。補齊后重新校驗文件系統仍然出現錯誤。再次檢查inode表,發現后離線磁盤損壞區域有部分節點表現異常。
北亞企安數據恢復——raid5數據恢復
雖然節點中描述的uid正常存在,但屬性,大小和最初的分配塊都是錯誤的。按照所有可能進行分析,但是沒有找到方法找回此損壞節點。只能試圖修復此節點或復制一個相同的文件過來。
11、針對所有可能存在錯誤的文件,北亞企安數據恢復工程師通過日志確定原節點塊的節點信息,然后做修正。
12、修正后重新dd根分區,執行fsck -fn /dev/sda5依然報錯。
北亞企安數據恢復——raid5數據恢復
根據報錯信息,北亞企安數據恢復工程師在系統中發現有多個節點共用同樣的數據塊。按此提示分析底層,發現存在節點信息的新舊交集。
13、按照節點所屬的文件進行區分,清除錯誤節點后再次執行fsck -fn /dev/sda5,依然有少量報錯。根據報錯信息,發現這些節點多位于doc目錄下,不影響系統啟動,于是直接執行fsck -fy /dev/sda5強行修復。
14、修復完成后重啟系統,成功進入系統桌面。
15、啟動oracle數據庫服務,啟動OA,一切正常無報錯。
16、由用戶方對恢復的操作系統和數據(OA和oracle數據庫)進行檢測,經過用戶方多方檢測,確認恢復數據完整有效。本次數據恢復工作完成。
審核編輯 黃宇
-
服務器
+關注
關注
12文章
9123瀏覽量
85324 -
數據恢復
+關注
關注
10文章
568瀏覽量
17432 -
RAID5
+關注
關注
0文章
113瀏覽量
12720
發布評論請先 登錄
相關推薦
評論