服務器存儲數據恢復環境&故障：

一臺光纖服務器存儲上有16塊FC硬盤，上層部署了Oracle數據庫。服務器存儲前面板2個硬盤指示燈顯示異常，存儲映射到linux操作系統上的卷掛載不上，業務中斷。

通過storage manager查看存儲狀態，發現邏輯卷狀態失敗。再查看物理磁盤狀態，發現其中一塊盤報告“警告”，硬盤指示燈顯示異常的2塊盤報告“失敗”。

將當前存儲的完整日志狀態備份下來，解析備份出來的存儲日志并獲得了關于邏輯卷結構的部分信息。

將16塊硬盤做好標記后從存儲中移除，對16塊FC盤進行測試發現16塊盤均能正常識別。檢測16塊盤的SMART狀態，結果和在storage manager中的報告一致。

服務器存儲數據恢復過程：

1、以只讀方式將所有磁盤進行扇區級別鏡像操作。在鏡像過程中發現其中一塊磁盤的鏡像速度很慢，結合先前檢測結果綜合判斷，該盤應該存在大量損壞以及不穩定扇區。對該硬盤進行壞道鏡像操作，在鏡像過程中同時觀察鏡像的速度和穩定性，發現該盤的壞道并不多，但是存在大量的讀取響應時間長的不穩定扇區。調整拷貝策略后繼續對該盤進行鏡像，同時觀察剩余盤鏡像的情況。

2、鏡像完成后查看日志，發現在storage manager和硬盤SMART狀態均沒有報錯的一塊也存在壞道，硬盤指示燈顯示異常的2塊盤均存在大量不規律的壞道分布。

ext3文件系統部分關鍵源數據信息被壞道破壞，只能等待所有磁盤鏡像完畢后，通過同一條帶進行xor以及根據文件系統上下文關系的方式手動修復被損壞的文件系統。

3、雖然鏡像速度很慢的那塊盤鏡像完成，但是拷貝策略導致現在的鏡像是不完整的，調整拷貝策略，繼續鏡像被跳過的扇區，直到該盤所有扇區全部鏡像完畢。

4、所有硬盤鏡像完成后，將所有硬盤按照標記還原到原存儲中，后續的數據分析和數據恢復操作都基于鏡像文件進行。避免后續操作對原始磁盤數據造成二次破壞。將所有鏡像文件全部發開，根據對ext3文件系統的逆向以及日志文件的分析，獲取到16塊FC盤在存儲中的盤序，RAID的塊大小，RAID的校驗走向和方式等信息。利用這些信息虛擬重組RAID，RAID搭建完成后進一步解析ext3文件系統。和用戶方溝通后提取出了一些oracle的dmp文件，嘗試進行恢復。

5、在通過dmp文件恢復數據的過程中，數據庫報告imp-0008錯誤。北亞企安數據恢復工程師分析導入dmp文件的日志文件后，發現恢復的dmp文件存在問題。

6、重新分析raid結構，進一步確定ext3文件系統被破壞的程度。重新恢復dmp文件和dbf原始庫文件，將恢復出來的dmp文件移交給用戶進行數據導入測試，測試結果順利且沒有發現問題。對恢復出來的dbf原始庫文件進行校驗檢測，所有文件均能通過測試。

oracle數據庫恢復過程：

1、拷貝數據庫文件到原數據庫服務器上的一個文件夾中作為備份。在根目錄下創建了一個oradata文件夾，并把備份的整個文件夾拷貝到oradata目錄下。更改oradata文件夾及其所有文件的屬組和權限。

2、備份原數據庫環境，包括ORACLE_HOME下product文件夾下的相關文件。

配置監聽，使用splplus連接到數據庫。嘗試啟動數據庫到nomount狀態。進行基本狀態查詢后，了解到環境和參數文件沒有問題。 嘗試啟動數據庫到mount狀態，進行狀態查詢沒有問題。啟動數據庫到open狀態時出現報錯。

北亞企安數據恢復—oracle數據恢復

3、經過進一步的檢測和分析，北亞企安數據恢復工程師判斷此故障為控制文件和數據文件信息不一致導致，這是一類因斷電或突然關機導致的故障。

4、對數據庫文件進行逐個檢測，發現所有數據文件沒有物理損壞。

5、在mount狀態下，對控制文件進行備份;對備份的控制文件進行查看修改，取得其中的重建控制文件命令。把這些命令復制到一個新建腳本文件controlfile.sql中。

6、關閉數據庫，刪除備份文件夾下的3個控制文件。 啟動數據庫到nomount狀態，執行controlfile.sql 腳本。

北亞企安數據恢復—oracle數據恢復

7、重建控制文件完成后直接啟動數據庫，仍然報錯，需要進一步處理。

北亞企安數據恢復—oracle數據恢復

執行恢復命令做介質恢復，直到返回報告，恢復完成。

北亞企安數據恢復—oracle數據恢復

8、嘗試open數據庫，數據庫啟動成功。把原來temp表空間的數據文件加入到對應的temp表空間中。

9、對數據庫進行各種常規檢查，沒有發現任何錯誤。

10、進行emp備份。全庫備份完成，沒有報錯。將應用程序連接到數據庫，進行應用層面的數據驗證。

11、數據驗證過程沒有發現任何問題，數據庫修復完成。本次數據恢復工作完成。