服務器存儲數據恢復環境&故障：
一臺存儲上有一組由16塊FC硬盤組建了一組raid。存儲前面板上的對應10號和13號硬盤的故障燈亮起，存儲映射到redhat linux操作系統服務器上的卷掛載不上，業務中斷。

服務器存儲數據恢復過程：
1、通過存儲的管理后臺查看當前存儲狀態，管理后臺報告邏輯卷狀態失敗。再查看物理磁盤狀態，發現6號盤狀態“警告”，10號和13號盤狀態“失敗”。在管理后臺將當前存儲的完整日志狀態備份。解析日志獲取到關于邏輯卷結構的部分信息。

北亞企安數據恢復—服務器數據恢復

2、將16塊FC盤做好標記后從存儲中移除，使用專用工具對16塊FC盤進行初步檢測， 發現16塊盤均能正常識別。檢測所有磁盤的SMART狀態，發現6號盤的SMART狀態為“警告”，和在存儲管理后臺中的報告一致。
3、將所有磁盤以只讀方式進行扇區級別的全盤鏡像。在鏡像過程中發現6號磁盤的鏡像速度很慢，結合之前的檢測結果綜合判斷，6號盤應該存在大量損壞和不穩定的扇區。
4、使用專業設備對6號硬盤進行鏡像，在鏡像的同時觀察鏡像的速度和穩定性。經過觀察發現6號盤的壞道并不多，但是存在大量讀取響應時間長的不穩定扇區。調整6號盤的鏡像策略后繼續對6號盤進行鏡像操作，同時觀察鏡像情況。6號盤鏡像完成，但是之前的鏡像策略會自動跳過一些不穩定扇區，所以現在的鏡像是不完整的。調整鏡像策略，繼續鏡像被跳過的扇區，直到6號盤所有扇區全部鏡像完畢。
5、全部磁盤做完鏡像后查看日志，發現在管理后臺和SMART狀態中均無報錯的1號盤也存在壞道，10號和13號盤也存在大量不規則壞道。定位到目標鏡像文件并經過分析，發現ext3文件系統的部分關鍵源數據信息已經被壞道破壞。只能利用6號盤通過同一條帶進行xor，并根據文件系統上下文關系手動修復被損壞的文件系統。
6、將所有鏡像文件全部展開。根據北亞企安數據恢復工程師對ext3文件系統的逆向研究和對日志文件的分析，獲取到16塊FC盤在存儲中的盤序、RAID塊大小、RAID的校驗走向和方式等信息。根據上述獲取到的信息虛擬重組RAID，RAID重組完成后進一步解析ext3文件系統。和用戶后溝通提取出一些oracle的dmp文件并嘗試進行恢復。
7、在使用dmp文件進行恢復的過程中，數據庫報告imp-0008錯誤。仔細分析導入dmp文件的日志文件，發現恢復的dmp文件有問題。重新分析raid結構，并進一步確定ext3文件系統被破壞的程度，重新恢復出dmp文件和dbf原始庫文件。將恢復出來的dmp文件移交給用戶進行數據導入測試，測試過程一切順利沒有發現問題。對恢復出來的dbf原始庫文件進行校驗檢測，所有文件均通過測試。
8、拷貝數據庫文件到原數據庫服務器作為備份，路徑為/home/oracle/tmp/syntong。在根目錄下創建了oradata文件夾，并把備份的syntong文件夾拷貝到oradata目錄下。更改oradata文件夾及其所有文件的屬組和權限。備份原數據庫環境，包括ORACLE_HOME下product文件夾下的相關文件。
9、配置監聽，使用原機中的splplus連接到數據庫。嘗試啟動數據庫到nomount狀態，狀態查詢發現環境和參數文件正常。 嘗試啟動數據庫到mount狀態，狀態查詢也沒有問題。啟動數據庫到open狀態，出現報錯。

北亞企安數據恢復—服務器數據恢復

10、經過檢測和分析，北亞企安數據恢復工程師判斷此故障原因是控制文件和數據文件信息不一致，這是一類由于異常斷電或突然關機引起的常見故障。
11、逐個檢測數據庫文件，沒有發現物理損毀。
12、在mount狀態下，備份控制文件。查看修改備份的控制文件，取得其中的重建控制文件命令。把命令復制到一個新建腳本文件controlfile.sql中。
13、關閉數據庫，刪除/oradata/syntong/下的3個控制文件。 啟動數據庫到nomount狀態，執行controlfile.sql腳本。

北亞企安數據恢復—服務器數據恢復

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

北亞企安數據恢復—服務器數據恢復

執行恢復命令：

北亞企安數據恢復—服務器數據恢復

做介質恢復，直到返回報告。
15、嘗試open數據庫。
SQL>alter database open resetlogs;
16、數據庫啟動成功。把原來temp表空間的數據文件加入到對應的temp表空間中。
17、對數據庫進行各種常規檢查，沒有任何錯誤。
18、進行emp備份。全庫備份完成，沒有報錯。
19、將應用程序連接到數據庫，在應用層面驗證數據。
20、經過驗證，用戶方確認數據完整有效，認可數據恢復結果。

審核編輯 黃宇