故障服務器上一共16塊FC硬盤，單盤容量600G。存儲前面板10號和13號硬盤亮黃燈，存儲映射到redhat上的卷掛載不上，服務器業務崩潰。
服務器數據恢復流程
通過IBM storage manager/frombyte.com連接到服務器上查看當前存儲狀態，服務器報告邏輯卷狀態失敗，再查看物理磁盤狀態，發現6號盤報告“警告”，10號和13號盤報告“失敗”，通過IBM storage manager將當前存儲的完整日誌狀態備份下來，解析備份出來的存儲日誌獲得了關於邏輯卷結構的部分信息。
服務器數據恢復工程師將16塊FC盤粘貼標籤，按照原始槽位號登記後從存儲中移除，使用數據恢復的FC盤鏡像設備“DELL R510+SUN3510”對16塊FC盤進行粗略測試，結果發現16塊盤均能正常識別，分別檢測16塊盤的SMART狀態，結果6號盤的SMART狀態爲“警告”狀態和在IBM storage manager中報告一致。
服務器數據恢復工程師在windows環境下首先將設備識別出來的FC盤在磁盤管理器中標記爲脫機狀態，從而爲原始磁盤提供了一個寫保護功能，然後使用winhex軟件對原始磁盤進行扇區級別鏡像操作，將原始磁盤中的所有物理扇區鏡像到windows系統下的邏輯磁盤並以文件形式保存。在鏡像過程中發現6號磁盤的鏡像速度很慢，結合先前對硬盤SMART狀態檢測時發現的問題綜合判斷，6號盤應該存在大量損壞以及不穩定扇區，導致在windows下的一般應用軟件無法對其進行操作。
使用專業壞道硬盤鏡像設備對6號硬盤進行壞道鏡像操作，在鏡像過程中同時觀察鏡像的速度和穩定性，發現6號盤的壞道並不多，但是存在大量的讀取響應時間長等不穩定扇區，於是調整6號盤的拷貝策略，將遇到壞道跳過扇區數和響應等待時間等參數均作一些修改。繼續對6號盤進行鏡像操作。同時觀察剩餘盤在windows環境下使用winhex鏡像的情況。
經過鏡像操作後，在windows平臺下使用winhex鏡像的磁盤已經全部鏡像完成，查看winhex生成的日誌，發現在IBM storage manager/frombyte.com和硬盤SMART狀態中均沒有報錯的1號盤也存在壞道，10號和13號盤均存在大量不規律的壞道分佈，根據壞道列表使用winhex定位到目標鏡像文件分析發現，ext3文件系統的一些關鍵源數據信息有的已經被壞道所破壞，只能等待6號盤鏡像完畢後，通過同一條帶進行xor以及根據文件系統上下文關係的方式手動修復被損壞的文件系統。
壞道鏡像設備報告6號盤鏡像完成，但是先前爲了最大限度做出有效扇區以及爲了保護磁頭設置的拷貝策略會自動跳過一些不穩定扇區，所以現在的鏡像是不完整的，於是調整拷貝策略，繼續鏡像被跳過的扇區，6號盤所有扇區全部鏡像完畢。
得到了所有硬盤的物理扇區鏡像，在windows平臺下使用winhex將所有鏡像文件全部展開，根據我們對ext3文件系統的逆向以及日誌文件的分析，得到了16塊FC盤在存儲中的盤序，RAID的塊大小，RAID的校驗走向和方式等信息，於是嘗試通過軟件的方式虛擬重組RAID，RAID搭建完成後進一步解析ext3文件系統，通過和用戶溝通提取出了一些oracle的dmp文件，用戶嘗試進行恢復。
在dmp恢復的過程中，oracle報告爲imp-0008錯誤，聯繫北亞的oracle工程師，通過仔細分析導入dmp文件的日誌文件，發現恢復的dmp文件存在問題而導致dmp導入數據失敗。立刻重新分析raid結構，以及進一步確定ext3文件系統被破壞的程度，又經過數小時的工作，重新恢復dmp文件和dbf原始庫文件，將恢復出來的dmp文件移交給用戶進行數據導入測試，結果測試順利沒有發現問題，說明這次的數據恢復是成功的，接着對恢復出來的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
2.經過進一步的檢測和分析，判斷此故障爲控制文件和數據文件信息不一致，這是一類因斷電或突然關機等引起的常見故障。
3.對數據庫文件進行逐個檢測，檢測到所有數據文件沒有物理損毀。
4.在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
7.重建控制文件完成後，直接啓動數據庫，報錯，需要進一步處理。
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備份。全庫備份完成，沒有報錯。將應用程序連接到數據庫，進行應用層面的數據驗證。
服務器數據恢復建議：
一旦服務器出現故障導致了數據丟失，首先應該將出現故障的服務器內所有運行正常的非熱備盤進行鏡像備份，將存在物理故障的硬盤進行保護，避免磕碰、進水等，如果與條件的可以進行簡單處理並藉助專業數據恢復工具將故障硬盤裏的數據也進行鏡像備份。得到鏡像數據後需要對數據進行分析，找出原來陣列中的結構參數以便重建服務器陣列及邏輯校驗，通過校驗後即可成功導出服務器數據。
如果服務器由於未知原因出現崩潰、無法啓動等數據丟失問題，切忌非專業人士在非潔淨空間內對服務器內的硬盤進行拆卸、更換磁頭等數據恢復操作，並且建議服務器管理員將故障硬盤進行妥善保管等待專業的數據恢復工程師進行處理。