故障伺服器上一共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備份。全庫備份完成，沒有報錯。將應用程式連線到資料庫，進行應用層面的資料驗證。
一旦伺服器出現故障導致了資料丟失，首先應該將出現故障的伺服器內所有執行正常的非熱備盤進行映象備份，將存在物理故障的硬碟進行保護，避免磕碰、進水等，如果與條件的可以進行簡單處理並借助專業資料恢復工具將故障硬碟裡的資料也進行映象備份。得到映象資料後需要對資料進行分析，找出原來陣列中的結構引數以便重建伺服器陣列及邏輯校驗，通過校驗後即可成功匯出伺服器資料。
如果伺服器由於未知原因出現崩潰、無法啟動等資料丟失問題，切忌非專業人士在非潔淨空間內對伺服器內的硬碟進行拆卸、更換磁頭等資料恢復操作，並且建議伺服器管理員將故障硬碟進行妥善保管等待專業的資料恢復工程師進行處理。
Sybase資料庫故障的修復方法
在 本問題之前，首先要為大家解釋一下syabse資料庫本身。syabse資料庫應用和本身的架構相對而言都相對比較複雜，多數技術人員及公司對sybase資料庫底層結構和執行機制也處於並非完全了解的階段，這就對sybase資料庫資料恢復和sybase資料庫資料修復造成了很大的阻礙。難道一旦sybase資...
rpmdb損壞的修復方法
背景 一次yum做更新的時候，強制終止了該程序，後來再使用yum的時候就報錯了 error cannot open providename index using db3 bad file descriptor 如報錯所述，rpmdb損壞，rpmdb簡單來說是用來儲存一些軟體包的依賴關係，解析安裝過...
損壞Word文件的幾種修復方法
損壞word文件的幾種修復方法 word 文件是許多電腦使用者寫作時使用的檔案格式，當您辛辛苦苦寫完一篇word文件後，發現它因損壞而無法開啟時，一定非常著急。其實，您不必心焦，因為我們還是有一些方法可以修復損壞文件，恢復受損文件中的文字。下面是具體的步驟。1 採用專用修復功能 在 檔案 選單上，單...