服務器存儲數據恢復環境：
某品牌光纖存儲上共有16塊FC硬盤。存儲上的卷映射到Linux操作系統上。Linux操作系統上運行Oracle數據庫。

服務器存儲故障&檢測：
存儲上2塊硬盤故障燈亮起，存儲映射到linux操作系統上的卷掛載不上，業務中斷。
使用storage manager連接到存儲查看存儲目前狀態，發現邏輯卷狀態失?。?號盤報告“警告”，10號盤和13號盤報告“失敗”；通過storage manager將當前存儲的完整日志狀態備份下來，解析備份的日志獲取關于邏輯卷結構的部分信息。
將16塊FC盤標記后從存儲中取出，使用專業設備檢測后發現16塊盤均能正常識別，6號盤的SMART狀態為“警告”，和在storage manager中的報告結果一致。
將所有磁盤以只讀方式進行扇區級全盤鏡像。在鏡像過程中觀察鏡像的速度和穩定性，發現6號盤的鏡像速度異常，結合之前檢測結果，基本上可以判斷6號盤應該存在損壞或者不穩定扇區。經過觀察發現6號盤的壞道并不多，但是存在大量的讀取響應時間長的不穩定扇區。調整鏡像策略繼續對6號盤做鏡像。
所有磁盤鏡像完成后，查看日志，發現在storage manager和硬盤SMART狀態檢測中均沒有發現問題的1號盤也存在壞道，10號和13號盤均存在大量不規律的壞道。根據壞道列表定位到目標鏡像文件，分析后發現ext3文件系統的部分關鍵源數據信息已經被壞道破壞。只能等所有磁盤鏡像完畢后，
通過同一條帶進行xor以及根據文件系統上下文關系手動修復被損壞的文件系統。
雖然通過調整鏡像策略完成6號盤的鏡像，但是調整后的鏡像策略會自動跳過一些不穩定扇區，所以做出來的鏡像是不完整的。再次調整鏡像策略，繼續鏡像被跳過的扇區，直到全部鏡像完成。
基于鏡像文件分析所有磁盤底層數據。通過對ext3文件系統的逆向分析以及對日志文件的分析，獲取到16塊FC盤在存儲中的盤序、RAID的塊大小、RAID的校驗走向和方式等重組RAID所需要的信息。嘗試使用上述獲取到的信息重組RAID，重組完成后解析ext3文件系統。和用戶溝通后，提取出一些oracle的dmp文件，用戶嘗試使用這些dmp文件恢復Oracle數據庫數據。
在使用dmp文件恢復Oracle數據庫的過程中，數據庫報告imp-0008錯誤。對導入dmp文件的日志文件進行分析，發現恢復出來的dmp文件存在問題。重新分析raid結構，進一步確定ext3文件系統被破壞的程度，重新恢復dmp文件和dbf原始庫文件。將恢復出來的dmp文件進行導入測試，這次沒有發現問題。對恢復出來的dbf原始庫文件進行校驗檢測，所有文件均能通過檢測。

Oracle數據庫恢復過程：
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、經過仔細驗證，用戶方確認數據庫數據沒有問題，認可數據恢復結果。

審核編輯 黃宇