IBM ds4700 兩塊硬碟掉線資料恢復過程
伺服器資料恢復背景
本次恢復資料的伺服器為一臺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狀態。出現報錯:
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備份。全庫備份完成,沒有報錯。將應用程式連線到資料庫,進行應用層面的資料驗證。一切正常,本次資料恢復成功。
本次恢復資料的伺服器為一臺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
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.com
- SQL>@controlfile.sql
點選(此處)摺疊或開啟
-
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備份。全庫備份完成,沒有報錯。將應用程式連線到資料庫,進行應用層面的資料驗證。一切正常,本次資料恢復成功。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2156336/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- IBM伺服器raid5兩塊硬碟離線資料恢復過程IBM伺服器AI硬碟資料恢復
- 儲存有兩塊硬碟離線恢復資料的過程硬碟
- 伺服器資料恢復,raid5兩塊硬碟掉線資料恢復案例伺服器資料恢復AI硬碟
- raid5陣列兩塊硬碟離線資料恢復過程AI陣列硬碟資料恢復
- V7000儲存兩塊硬碟掉線資料恢復成功案例硬碟資料恢復
- RAID磁碟陣列掉線3塊的資料恢復過程AI陣列資料恢復
- raid5硬碟掉線,重建raid並同步資料後恢復資料過程AI硬碟
- 別太相信陣列的安全性:兩塊硬碟離線資料恢復過程陣列硬碟資料恢復
- 資料恢復經典案例分析-raid兩塊硬碟離線恢復資料恢復AI硬碟
- 【伺服器資料恢復】Raid5陣列兩塊硬碟亮黃燈掉線的資料恢復案例伺服器資料恢復AI陣列硬碟
- StorNext伺服器資料恢復案例;硬碟掉線資料恢復伺服器資料恢復硬碟
- raid5磁碟陣列2塊硬碟離線資料恢復過程AI陣列硬碟資料恢復
- 銀行伺服器有4塊硬碟掉線資料恢復案例伺服器硬碟資料恢復
- 伺服器raid5先後兩塊盤掉線的恢復過程伺服器AI
- IBM伺服器硬碟離線資料恢復方法IBM伺服器硬碟資料恢復
- raid5陣列兩塊硬碟出現物理故障的資料恢復過程AI陣列硬碟資料恢復
- 【北亞資料恢復】DELL POWEREDGE 2850伺服器RAID5兩塊硬碟掉線後系統癱瘓的資料恢復資料恢復伺服器AI硬碟
- 伺服器硬碟意外離線的資料恢復過程伺服器硬碟資料恢復
- 【伺服器資料恢復】多塊硬碟掉線導致儲存LUN不可用的資料恢復伺服器資料恢復硬碟
- 【伺服器資料恢復】農科院某研究所DELL伺服器raid5兩塊硬碟掉線的資料恢復伺服器資料恢復AI硬碟
- 【伺服器資料恢復】伺服器raid5陣列2塊硬碟掉線的資料恢復案例伺服器資料恢復AI陣列硬碟
- raid5硬碟故障資料恢復過程AI硬碟資料恢復
- 【北亞資料恢復】raid5在熱備盤同步資料過程中,硬碟掉線導致raid崩潰的資料恢復案例資料恢復AI硬碟
- 儲存硬碟故障後強制上線恢復所有資料過程硬碟
- 【伺服器資料恢復】資料庫所在raid陣列硬碟故障掉線的資料恢復案例伺服器資料恢復資料庫AI陣列硬碟
- raid5陣列2塊硬碟掉線應該資料恢復還是強制上線AI陣列硬碟資料恢復
- 【北亞資料恢復】IBM FlashSystem儲存raid5多硬碟離線的資料恢復案例資料恢復IBMAI硬碟
- 【伺服器資料恢復】掉線硬碟重新上線同步資料被中斷後資料丟失的資料恢復伺服器資料恢復硬碟
- raid5硬碟同步過程中另一塊硬碟掉線怎麼辦AI硬碟
- 【北亞資料恢復】IBM3650伺服器raid5故障硬碟離線的資料恢復案例資料恢復IBM伺服器AI硬碟
- 【伺服器資料恢復】HP EVA儲存多塊硬碟離線的資料恢復案例伺服器資料恢復硬碟
- 【北亞資料恢復】HP P2000伺服器 RAID5硬碟故障掉線的資料恢復資料恢復伺服器AI硬碟
- raid5兩塊硬碟離線lvm下vxfs檔案系統恢復資料方案AI硬碟LVM
- 資料恢復記錄:硬碟分割槽損壞修復SqlServer資料庫過程資料恢復硬碟SQLServer資料庫
- 資料庫恢復過程資料庫
- 【伺服器資料恢復】RAID6多塊硬碟離線崩潰的資料恢復案例伺服器資料恢復AI硬碟
- 硬碟資料恢復硬碟資料恢復
- 【伺服器資料恢復】IBM儲存伺服器硬碟壞道離線、oracle資料庫損壞的資料恢復伺服器資料恢復IBM硬碟Oracle資料庫