【伺服器資料恢復】IBM儲存伺服器硬碟壞道離線、oracle資料庫損壞的資料恢復

北亞資料恢復發表於2022-04-25

伺服器資料恢復環境:

IBM某型號儲存伺服器;

16塊單盤容量600G的FC硬碟。


伺服器故障:

指向10號和13號硬碟的指示燈顯示為黃色;

儲存對映到redhat上的卷掛載不上,業務中斷。


儲存伺服器資料恢復過程:


1、通過IBM storage manager連線到伺服器上檢視當前儲存狀態:伺服器報告邏輯卷狀態失敗,6號盤報告“警告”,10號

和13號盤報告“失敗”。

2、通過IBM storage manager將當前儲存的完整日誌狀態備份下來,解析備份出來的儲存日誌獲取關於邏輯卷結構的部分信

息。


3、伺服器資料恢復工程師將16塊FC盤做好標記,按照原始槽位號登記後把這16塊FC硬碟從儲存中取出。使用資料恢復使用

的FC盤映象裝置對16塊FC盤進行粗略測試,均能正常識別;對16塊盤的SMART狀態進行檢測,6號盤的SMART狀態為

“警告”,和在IBM storage manager中報告一致。


4、資料恢復工程師在windows環境下將裝置識別出來的FC盤在磁碟管理器中標記為離線狀態,對原始磁碟防寫。然後對

原始磁碟進行扇區級別映象備份,將原始磁碟中的所有物理扇區映象到windows系統下的邏輯磁碟並以檔案形式儲存。映象

過程中6號磁碟的映象速度不正常,結合之前6號磁碟的SMART狀態,可以判斷6號盤存在損壞和不穩定扇區。


5、使用壞道硬碟專用映象裝置對6號硬碟進行備份,發現6號盤的壞道不多,但是存在大量讀取響應時間長的不穩定扇區。

調整拷貝策略對6號盤進行映象備份。


6、完成所有磁碟映象後,對生成的日誌進行分析,發現在IBM storage manager和硬碟SMART狀態中均沒有報錯的1號盤

存在壞道,10號和13號盤均存在大量不規律的壞道分佈。根據壞道列表定位到目標映象檔案,發現ext3檔案系統的部分關鍵

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

損壞的檔案系統。


7、雖然壞道映象裝置對6號盤的映象完成,但是先前的拷貝策略會自動跳過一些不穩定扇區,所以做出來的映象是不完整的,

調整拷貝策略,繼續映象被跳過的扇區,完成6號盤所有扇區的映象。


8、完成所有硬碟映象後,根據對ext3檔案系統的逆向以及日誌檔案的分析,獲取到16塊FC盤在儲存中的盤序,RAID的塊大

小,RAID的校驗走向和方式等資訊。利用獲取到的資訊虛擬重組RAID,完成RAID搭建後進一步解析ext3檔案系統,通過和

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


9、在利用dmp檔案進行資料恢復的過程中,oracle報告imp-0008錯誤。北亞的oracle工程師通過分析匯入dmp檔案的日誌

檔案,發現恢復出來的dmp檔案存在問題。


10、重新分析raid結構,進一步確定ext3檔案系統被破壞的程度。經過數小時的努力,重新恢復出來dmp檔案和dbf原始庫

檔案,將恢復出來的dmp檔案進行資料匯入測試,沒有出現問題,證明了這次恢復出來的資料是沒有問題的。


11、對恢復出來的dbf原始庫檔案進行校驗檢測,所有檔案均能通過測試。


12、和伺服器管理員進行溝通後,最終決定使用恢復出來的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、在mount狀態下對控制檔案進行備份,alter database backup controlfile to trace as ' /backup/controlfile'。對備份

的控制檔案進行檢視修改,取得其中的重建控制檔案命令。把這些命令複製到一個新建指令碼檔案controlfile.sql中。


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

SQL>startup nomount/frombyte.com

SQL>@controlfile.sql


6、重建控制檔案完成後,啟動資料庫報錯,需要進一步處理。

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

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


7、嘗試open資料庫。

SQL> alter database open resetlogs;


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


9、對資料庫進行各種常規檢查,沒有任何錯誤。


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


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2888570/,如需轉載,請註明出處,否則將追究法律責任。

相關文章