【北亞資料恢復】IBM DS系列儲存伺服器硬碟故障、對映出錯的資料恢復

伺服器資料恢復環境：

IBM DS系列儲存伺服器；

16塊容量600G的FC硬碟。

故障：

儲存伺服器前皮膚10號和13號硬碟故障燈亮，儲存對映到redhat上的卷掛載不上，業務下線。伺服器管理員聯絡北亞資料

恢復中心進行伺服器資料恢復。

伺服器資料備份和測試過程：

1、到現場後，北亞資料恢復工程師通過storage manager連線到儲存檢視當前儲存狀態，儲存報告邏輯卷狀態失敗。物理

磁碟狀態：6號盤報告“警告”，10號和13號盤報告“失敗”。

2、通過storage manager將當前儲存的完整日誌備份下來，通過解析備份出來的儲存日誌，北亞資料恢復工程師獲取了關

於邏輯卷結構的部分資訊。

3、將16塊FC盤貼上標籤，按照原始槽位號登記後從儲存中移除，使用FC盤映象裝置“R510+SUN3510”對16塊FC盤進

行粗略測試，16塊盤均能正常識別。分別檢測16塊盤的SMART狀態，發現6號盤的SMART狀態為“警告”，和在IBM 

storage manager中報告一致。

4、在windows環境下將裝置識別出來的FC盤在磁碟管理器中標記為離線狀態，為原始磁碟提供一個防寫功能。北亞數

據恢復工程師然後使用軟體對原始磁碟進行扇區級別映象操作，將原始磁碟中的所有物理扇區映象到邏輯磁碟並以檔案形

式儲存。在映象過程中發現6號磁碟的映象速度很慢，結合先前對硬碟SMART狀態檢測時發現的問題綜合判斷，6號盤應

該存在大量損壞以及不穩定扇區，導致一般應用軟體無法對其進行操作。

5、使用壞道硬碟映象裝置對6號硬碟進行壞道映象操作，在映象過程中同時觀察映象的速度和穩定性，發現6號盤的壞道

多，但是存在大量的讀取響應時間長的不穩定扇區。於是北亞資料恢復工程師調整6號盤的拷貝策略，將“遇到壞道跳過

扇區數”和“響應等待時間”等引數做修改後繼續對6號盤進行映象操作。同時觀察剩餘盤映象的情況。

6、完成全部映象後檢視日誌，發現在storage manager和硬碟SMART狀態中均沒有報錯的1號盤也存在壞道，10號和13

號盤均存在大量不規律的壞道分佈，通過使用軟體定位到目標映象檔案分析壞道列表發現，ext3檔案系統的部分關鍵源數

據資訊已經被壞道破壞，只能等待6號盤映象完畢後，通過同一條帶進行xor以及根據檔案系統上下文關係的方式手動修復

被損壞的檔案系統。

7、6號盤映象完成，但是先前為了最大限度備份出有效扇區以及為了保護磁頭設定的拷貝策略會自動跳過一些不穩定扇區

，所以現在的映象是不完整的。北亞資料恢復工程師調整拷貝策略，繼續映象被跳過的扇區，完成6號盤所有扇區的全部鏡

像。

8、得到了所有硬碟的物理扇區映象，在平臺下使用軟體將所有映象檔案全部展開，根據對ext3檔案系統的逆向以及日誌文

件的分析，北亞資料恢復工程師獲取到了16塊FC盤在儲存中的盤序、RAID的塊大小、RAID的校驗走向和方式等資訊。北

亞資料恢復工程師嘗試通過軟體的方式虛擬重組RAID，RAID搭建完成後進一步解析ext3檔案系統，通過和伺服器管理員

溝通提取出了一些oracle的dmp檔案，伺服器管理員嘗試進行恢復。

9、在dmp恢復的過程中，資料庫報告imp-0008錯誤，通過仔細分析匯入dmp檔案的日誌檔案，北亞資料恢復工程師發現

恢復的dmp檔案存在問題所以導致dmp匯入資料失敗。北亞資料恢復工程師立刻重新分析raid結構，進一步確定ext3檔案

系統被破壞的程度。經過數小時的努力，重新恢復dmp檔案和dbf原始庫檔案，將恢復出來的dmp檔案移交給伺服器管理

員進行資料匯入測試，測試沒有發現問題。然後對恢復出來的dbf原始庫檔案進行校驗檢測，所有檔案均能通過測試。

伺服器資料庫恢復流程：

1、 拷貝資料庫檔案到原資料庫伺服器，路徑為/home/oracle/tmp/syntong作為備份。在根目錄下建立了一個oradata

資料夾，把備份的整個syntong資料夾拷貝到oradata目錄下，然後更改oradata資料夾及其所有檔案的屬組和許可權。

2.、備份原資料庫環境，包括ORACLE_HOME下product資料夾下的相關檔案。配置監聽，使用原機中的splplus連線到

資料庫。嘗試啟動資料庫到nomount狀態。進行基本狀態查詢後，確認環境和引數檔案沒有問題。 嘗試啟動資料庫到

mount狀態，進行狀態查詢沒有問題。啟動資料庫到open狀態。出現報錯：

3. 經過進一步的檢測和分析，北亞資料恢復工程師判斷此故障為控制檔案和資料檔案資訊不一致，這是一類因斷電或突然

關機等引起的常見故障。

4. 對資料庫檔案進行逐個檢測，檢測到所有資料庫檔案沒有物理損毀。

5.  在mount狀態下，北亞資料恢復工程師對控制檔案進行備份，alter database backup controlfile to trace as 

' /backup/controlfile'；對備份的控制檔案進行檢視修改，取得其中的重建控制檔案命令。把這些命令複製到一個新建指令碼

檔案controlfile.sql中。

6.  關閉資料庫，刪除/oradata/syntong/下的3個控制檔案。 啟動資料庫到nomount狀態，執行controlfile.sql 指令碼。

7. 重建控制檔案完成後，直接啟動資料庫，報錯，需要進一步處理。

然後執行恢復命令：

做介質恢復，直到返回報告，恢復完成。

8. 嘗試open資料庫。

SQL> alter database open resetlogs;

9.  資料庫啟動成功。把原來temp表空間的資料檔案加入到對應的temp表空間中。

10. 對資料庫進行各種常規檢查，沒有任何錯誤。

11. 進行emp備份。全庫備份完成，沒有報錯。將應用程式連線到資料庫，進行應用層面的資料驗證。

12、資料驗證結束，資料庫修復完成，資料恢復成功。