1. 程式人生 > >IBM ds4700存儲硬盤離線數據恢復-北亞案例

IBM ds4700存儲硬盤離線數據恢復-北亞案例

生成 erro 服務器型號 常見 tar mar 邏輯卷 start 移除

服務器數據恢復背景

本次恢復數據的服務器為一臺IBM DS4700 光纖存儲,該公司管理員提供的信息如下:服務器型號為IBM DS4700 存儲,掛載14塊硬盤,存儲oracle數據庫,兩塊硬盤報黃燈錯誤,目前raid組崩潰/卷無法掛載/業務全部癱瘓,需要進行緊急數據恢復處理。

服務器數據恢復檢測過程

服務器數據恢復工程師首先對服務器進行檢查,通過IBM storage manager/frombyte.com連接存儲查看服務器存儲當前狀態,存儲報告邏輯卷狀態失敗。然後對物理磁盤狀態進行查看,發現13號磁盤狀態為“警告”,10號和11號磁盤狀態為“失敗”,繼續使用IBM storage manager對當前存儲的全部日誌進行備份解析邏輯卷結構信息,以備後期數據恢復使用。

客戶管理員在服務器數據恢復工程師的幫助下將服務器全部磁盤進行編號標記,按各自槽位登記並移除服務器移交硬盤數據恢復工程師進行物理檢測。工程師通過PC盤鏡像設備對全部硬盤進行簡單檢測,所有硬盤可以正常識別,13號盤SMART狀態為“警告”,狀態和在IBM storage manager中報告一致。

服務器全盤備份

服務器數據恢復工程師在windows環境下首先將設備可以識別的磁盤在磁盤管理器中標記為脫機狀態,從而為原始磁盤提供了一個寫保護功能,然後使用數據恢復軟件軟件對原始磁盤進行扇區級別鏡像操作,將原始磁盤中的所有物理扇區鏡像到windows系統下的邏輯磁盤並以文件形式保存。(在鏡像過程中13號硬盤的鏡像速度極其緩慢,初步判斷該盤存在大量不穩定扇區及損壞,需要使用壞道硬盤鏡像設備進行備份)使用專業壞道硬盤鏡像設備對13號硬盤進行壞道鏡像同時觀察鏡像的速度和穩定性,發現13號盤的壞道並不多,但是存在大量的讀取響應時間長等不穩定扇區,於是調整該磁盤的拷貝策略,將遇到壞道跳過扇區數和響應等待時間等參數均作一些修改。繼續對該磁盤進行鏡像操作。同時觀察剩余盤在windows環境下使用winhex鏡像的情況。

經過鏡像操作後,在windows平臺下使用winhex鏡像的磁盤已經全部鏡像完成,查看winhex生成的日誌,發現在IBM storage manager/frombyte.com和硬盤SMART狀態中均沒有報錯的1號盤也存在壞道,10號和11號盤均存在大量不規律的壞道分布。使用數據恢復工具結合壞道列表情況進行分析,EXT3文件系統中的部分關鍵性源數據處於壞道區域已被破壞,目前的數據恢復方案只能使用13號硬盤的鏡像文件進行同一條帶的xor並且根據文件系統的上下關系進行手動修復損壞的文件系統(13號盤不穩定扇區極多,硬盤數據恢復工程師為盡可能拷貝有效扇區並保護磁頭,在鏡像時對拷貝策略進行了部分自動跳過壞扇區的調整,鏡像文件也可能存在缺損)。

重組raid陣列

服務器數據恢復工程師在windows平臺下借助數據恢復工具將所有鏡像文件全部展開,通過我們對ext3文件系統的逆向以及日誌文件的分析得出服務器中所有磁盤在存儲中的盤序信息以及raid校驗方向、raid塊大小、raid校驗方式等信息,通過數據恢復工具對原raid進行虛擬重組、解析EXT3文件系統,將oracle數據庫中的dmp文件進行部分提取,嘗試進行數據恢復。

恢復oracle數據庫

在dmp恢復的過程中,oracle數據庫出現報錯,內容為“imp-0008”錯誤,數據庫數據恢復工程師對數據庫進行分析,導致數據庫報錯的原因為dmp文件有問題。服務器數據恢復工程師重新對raid結構進行分析重組,重新導出dmp文件和dbf原始庫文件並測試,接著對恢復出來的dbf原始庫文件進行校驗檢測,所有文件均能通過測試。
數據庫工程師到達現場,和用戶溝通後決定使用恢復出來的dbf原始庫文件進行操作,以確保能把數據恢復到最佳狀態。

數據庫恢復過程

1.把數據庫文件拷貝到原數據庫服務器中,路徑為/home/oracle/tmp/syntong.
在根目錄下創建了一個oradata文件夾作為備份,並把備份的整個syntong文件夾拷貝到oradata目錄下。然後更改oradata文件夾及其所有文件的屬組和權限。
2.備份原數據庫環境,包括ORACLE_HOME下product文件夾下的相關文件。配置監聽,使用原機中的splplus連接到數據庫。嘗試啟動數據庫到nomount狀態。進行基本狀態查詢後,了解到環境和參數文件沒有問題。 嘗試啟動數據庫到mount狀態,進行狀態查詢沒有問題。啟動數據庫到open狀態。出現報錯:
ORA-01122: database file 1 failed verification check/frombyte.com
ORA-01110: data file 1: ‘/oradata/syntong/system01.dbf‘
ORA-01207: file is more recent than control file - old control file
3.經過進一步的檢測和分析,判斷此故障為控制文件和數據文件信息不一致,這是一類因斷電或突然關機等引起的常見故障。
4.對數據庫文件進行逐個檢測,檢測到所有數據文件沒有物理損毀。
5.在mount狀態下,對控制文件進行備份,alter database backup controlfile to trace as ‘ /backup/controlfile‘;對備份的控制文件進行查看修改,取得其中的重建控制文件命令。把這些命令復制到一個新建腳本文件controlfile.sql中。
6.關閉數據庫,刪除/oradata/syntong/下的3個控制文件。 啟動數據庫到nomount狀態,執行controlfile.sql 腳本。
SQL>startup nomount/frombyte.comSQL>@controlfile.sql
br/>SQL>@controlfile.sql
7.重建控制文件完成後,直接啟動數據庫,報錯,需要進一步處理。
SQL> alter database open;
alter database open/frombyte.com
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: ‘/free/oracle/oradata/orcl/system01.dbf‘
然後執行恢復命令:
recover database using backup controlfile until cancel;
Recovery of Online Redo Log: Thread 1 Group 1 Seq 22 Reading mem 0
Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log

做介質恢復,直到返回報告,恢復完成。
8.嘗試open數據庫。
SQL> alter database open resetlogs;
9.數據庫啟動成功。把原來temp表空間的數據文件加入到對應的temp表空間中。
10.對數據庫進行各種常規檢查,沒有任何錯誤。
11.進行emp備份。全庫備份完成,沒有報錯。將應用程序連接到數據庫,進行應用層面的數據驗證。一切正常,本次數據恢復成功。

IBM ds4700存儲硬盤離線數據恢復-北亞案例