在服務(wù)器運維過程中，硬盤掉線是導(dǎo)致服務(wù)器故障、數(shù)據(jù)丟失的常見原因。針對普通服務(wù)器硬盤掉線引發(fā)的數(shù)據(jù)丟失問題，存在一套常規(guī)的數(shù)據(jù)恢復(fù)方法。下面將詳細介紹北亞數(shù)據(jù)恢復(fù)中心為某客戶服務(wù)器進行數(shù)據(jù)恢復(fù)的全過程。

服務(wù)器故障：
故障服務(wù)器配備了16塊硬盤。某一天，運維人員發(fā)現(xiàn)10號和13號硬盤亮黃燈，服務(wù)器業(yè)務(wù)隨即中斷。

服務(wù)器數(shù)據(jù)恢復(fù)過程：
1、服務(wù)器狀態(tài)查詢與日志備份分析
借助服務(wù)器管理工具連接到服務(wù)器，對服務(wù)器狀態(tài)進行查詢。結(jié)果顯示，服務(wù)器報告邏輯卷狀態(tài)失敗，物理硬盤狀態(tài)方面，6號盤報告“警告”，10號和13號盤報告“失敗”。對當(dāng)前服務(wù)器的日志進行完整備份，同時分析日志內(nèi)容，獲取部分邏輯卷信息，這些信息將用于后續(xù)的數(shù)據(jù)恢復(fù)。
2、硬盤編號、移除與檢測
將服務(wù)器內(nèi)的所有硬盤按照既定的順序和編號規(guī)則進行編號標記，然后將硬盤從服務(wù)器中取出。使用數(shù)據(jù)恢復(fù)鏡像設(shè)備對所有硬盤進行檢測，結(jié)果顯示16塊硬盤均能被正常識別。分別檢測這16塊硬盤的SMART狀態(tài)，發(fā)現(xiàn)6號盤的SMART狀態(tài)為“警告”，與在服務(wù)器管理工具中的報告一致。
3、磁盤鏡像操作
在Windows環(huán)境下，首先將設(shè)備識別出的FC盤在磁盤管理器中標記為脫機狀態(tài)，以提供寫保護。接著使用winhex軟件對原始磁盤進行扇區(qū)級別鏡像操作，將原始磁盤的所有物理扇區(qū)鏡像到Windows系統(tǒng)下的邏輯磁盤，并保存為文件。鏡像過程中發(fā)現(xiàn)，6號磁盤的鏡像速度極慢。結(jié)合之前對硬盤SMART狀態(tài)的檢測情況判斷，6號盤存在大量損壞和不穩(wěn)定扇區(qū)，導(dǎo)致Windows下的一般應(yīng)用軟件無法對其進行操作。
4、6號硬盤壞道鏡像處理
采用專業(yè)壞道硬盤鏡像設(shè)備對6號硬盤進行壞道鏡像操作。在鏡像過程中，密切觀察鏡像的速度和穩(wěn)定性。發(fā)現(xiàn)6號盤壞道數(shù)量不多，但存在大量讀取響應(yīng)時間長的不穩(wěn)定扇區(qū)。于是，調(diào)整6號盤的拷貝策略，修改遇到壞道跳過扇區(qū)數(shù)和響應(yīng)等待時間等參數(shù)，繼續(xù)進行鏡像操作，同時關(guān)注剩余硬盤在Windows環(huán)境下使用winhex鏡像的情況。
5、鏡像結(jié)果分析與文件系統(tǒng)修復(fù)準備
經(jīng)過鏡像操作，Windows平臺下使用winhex鏡像的磁盤全部完成。查看winhex生成的日志發(fā)現(xiàn)，在服務(wù)器管理工具和硬盤SMART狀態(tài)中均未報錯的1號盤也存在壞道，10號和13號盤存在大量不規(guī)律的壞道分布。根據(jù)壞道列表，使用winhex定位到目標鏡像文件進行分析，發(fā)現(xiàn)ext3文件系統(tǒng)的一些關(guān)鍵源數(shù)據(jù)信息已被壞道破壞。北亞企安數(shù)據(jù)恢復(fù)工程師只能等待6號盤鏡像完成后，通過同一條帶進行xor以及依據(jù)文件系統(tǒng)上下文關(guān)系手動修復(fù)被損壞的文件系統(tǒng)。
6、6號盤完整鏡像
壞道鏡像設(shè)備報告6號盤鏡像完成，但由于之前為保護磁頭和獲取有效扇區(qū)而設(shè)置的拷貝策略自動跳過了一些不穩(wěn)定扇區(qū)，鏡像并不完整。因此，再次調(diào)整拷貝策略，繼續(xù)鏡像被跳過的扇區(qū)，直至6號盤所有扇區(qū)全部鏡像完畢。
7、RAID虛擬重組與數(shù)據(jù)恢復(fù)
獲得所有硬盤的物理扇區(qū)鏡像后，在Windows平臺下使用winhex展開所有鏡像文件。北亞企安數(shù)據(jù)恢復(fù)工程師通過對ext3文件系統(tǒng)的逆向分析以及日志文件的研究，確定了16塊FC盤在存儲中的盤序、RAID的塊大小、RAID的校驗走向和方式等信息。隨后，嘗試通過軟件方式虛擬重組RAID。RAID搭建完成后，進一步解析ext3文件系統(tǒng)，并與用戶溝通，提取出一些oracle的dmp文件供用戶嘗試恢復(fù)。
8、數(shù)據(jù)恢復(fù)測試與成功
在dmp恢復(fù)過程中，oracle報告imp-0008錯誤。北亞數(shù)據(jù)恢復(fù)中心的oracle工程師仔細分析導(dǎo)入dmp文件的日志，發(fā)現(xiàn)恢復(fù)的dmp文件存在問題導(dǎo)致導(dǎo)入失敗。北亞企安數(shù)據(jù)恢復(fù)工程師隨即重新分析raid結(jié)構(gòu)，進一步確定ext3文件系統(tǒng)的破壞程度。經(jīng)過數(shù)小時的努力，重新恢復(fù)dmp文件和dbf原始庫文件。將恢復(fù)的dmp文件交給用戶進行數(shù)據(jù)導(dǎo)入測試，測試順利通過，未發(fā)現(xiàn)問題，數(shù)據(jù)恢復(fù)成功。最后，對恢復(fù)的dbf原始庫文件進行校驗檢測，所有文件均通過測試，本次服務(wù)器數(shù)據(jù)恢復(fù)圓滿完成。

審核編輯 黃宇