服務(wù)器數(shù)據(jù)恢復(fù)環(huán)境:
新網(wǎng)企業(yè)郵件服務(wù)器;
組建RAID5,文件系統(tǒng)為REISERFS;
一個數(shù)據(jù)分區(qū),存放上百萬企業(yè)用戶的郵件。
服務(wù)器故障&分析:
服務(wù)器在正常運行過程中,RAID突然OFFLINE。管理員檢查發(fā)現(xiàn)故障服務(wù)器有兩塊盤報警,將其中一塊盤強制上線后卻發(fā)現(xiàn)卷無法掛載,于是執(zhí)行FSCK并REBULD TREE,完成上述操作后卷仍然無法掛載。咨詢多家數(shù)據(jù)恢復(fù)服務(wù)商均無法提供可行的解決方案,最終新網(wǎng)選擇我們數(shù)據(jù)恢復(fù)中心進行數(shù)據(jù)恢復(fù)。
這種RAID故障在我們數(shù)據(jù)恢復(fù)中心接到的cases中是很常見的。因為報警的兩塊盤并不是同時掉線,如果強制上線先離線的硬盤會導(dǎo)致數(shù)據(jù)區(qū)的新舊數(shù)據(jù)混在一起,文件系統(tǒng)結(jié)構(gòu)不一致。強制上線會在讀寫過程中生成新的檢驗條帶,會影響一部分數(shù)據(jù)。如果讀寫不多或根本無法MOUNT,情況的嚴重性會小很多。
本案例中最嚴重的問題在于REBUILD TREE,此操作相當于將一個混雜的文件系統(tǒng)連續(xù)化,結(jié)果會導(dǎo)致文件系統(tǒng)的所有結(jié)構(gòu)體全面出錯,這種情況通常是無法挽救的。加上用戶的文件目錄結(jié)構(gòu)非常復(fù)雜,文件總數(shù)粗略估計上億,恢復(fù)數(shù)據(jù)的機會很小。
服務(wù)器數(shù)據(jù)恢復(fù)過程:
1、首先對故障服務(wù)器所有硬盤做鏡像備份,后續(xù)的數(shù)據(jù)恢復(fù)操作都在備份文件上進行,避免對數(shù)據(jù)二次破壞。
2、服務(wù)器數(shù)據(jù)恢復(fù)工程師先試圖將文件系統(tǒng)結(jié)構(gòu)區(qū)單獨提出來進行分析,但REISERFS文件系統(tǒng)區(qū)相對分散且無規(guī)律,通過北亞自主研發(fā)的程序?qū)ξ募到y(tǒng)結(jié)構(gòu)區(qū)進行提取和分析。在本案例中,僅1級節(jié)點提取出來的數(shù)據(jù)就有好幾個G,可見本案例文件結(jié)構(gòu)的復(fù)雜。
3、對文件系統(tǒng)區(qū)進行一致性檢驗,修正錯誤地方。本案例中好多文件系統(tǒng)節(jié)點區(qū)都因檢驗關(guān)系,使關(guān)鍵屬性字節(jié)發(fā)生了改變。通過北亞自主研發(fā)的程序?qū)⑺泄?jié)點狀態(tài)統(tǒng)一初始化,對節(jié)點進行一致性處理。
4、完成上述兩步操作后有2種方案恢復(fù)最終的數(shù)據(jù):
第一種方案:在LINUX系統(tǒng)下再次執(zhí)行FSCK,結(jié)果實施這種方案后發(fā)現(xiàn)效果不好,原因是LINUX FSCK的功能有限,如果在父節(jié)點稍有錯誤,其子節(jié)點便會被全部打入到LOST+FOUND里,無法還原原本的目錄結(jié)構(gòu)。
第二種方案:通過只讀方式,在WINDOWS環(huán)境下用北亞自主研發(fā)的程序提取數(shù)據(jù)。在具體的實施過程中,需要不斷修改程序并忽略一些錯誤,最終提取出數(shù)據(jù)。
5、由用戶對恢復(fù)出來的數(shù)據(jù)進行檢測,確認需要的數(shù)據(jù)基本都恢復(fù)出來,可以正常讀取。
服務(wù)器數(shù)據(jù)恢復(fù)總結(jié):
RAID5磁盤陣列兩塊硬盤先后離線,但是又不知道離線先后順序的case很多。碰到這種情況需要我們謹慎處理。如果可以查詢到日志,通過日志確定為好。如果強制上線出錯,應(yīng)馬上停止操作,切不可做FSCK等操作。
LINUX的FSCK操作風險很大,做之前一定要看清楚提示,如果出錯信息異常,應(yīng)選擇其他方案。
審核編輯:湯梓紅
-
服務(wù)器
+關(guān)注
關(guān)注
12文章
9231瀏覽量
85626 -
RAID
+關(guān)注
關(guān)注
0文章
278瀏覽量
35114 -
數(shù)據(jù)恢復(fù)
+關(guān)注
關(guān)注
10文章
580瀏覽量
17523
發(fā)布評論請先 登錄
相關(guān)推薦
評論