解析IBM x3850 RAID5伺服器故障恢復方案
【基本資訊】
伺服器型號:IBM X3850 伺服器,
硬碟型號:73G SAS 硬碟,
硬碟數量:5 塊硬碟 其中 4 塊組成一個 RAID5 ,另一塊做為熱備盤 (Hot-Spare) ,
作業系統:linux redhat 5.3, 應用系統為構架於 oracle 的一個 oa 。
【故障表現】
3 號盤早已經離線,但熱備盤未自動啟用 rebuild (原因不明),之後 2 號盤離線, RAID 崩潰。
oracle 已經不再對本 oa 系統提供後續支援,使用者要求儘可能資料恢復 + 作業系統復原。
【初檢結論】
熱備盤完全無啟用,硬碟無明顯物理故障,無明顯同步表現。資料通常可恢復。
【恢復方案】
1 、保護原環境,關閉伺服器,確保在恢復過程中不再開啟伺服器。
2 、把故障硬碟編號排序,用以確保硬碟取出槽位後可以完全復原。
3 、將故障硬碟掛載至只讀環境,對所有故障硬碟做完全映象 ( 參考 < 如何對磁碟做完整的全盤映象備份 >) 。備份完成後交回原故障盤,之後的恢復操作直到資料確認無誤前不再涉及原故障盤。
4 、對備份盤進行 RAID 結構分析,得到其原來的 RAID 級別,條帶規則,條帶大小,校驗方向, META 區域等。
5 、根據得到的 RAID 資訊搭建一組虛擬的 RAID5 環境。
6 、進行虛擬磁碟及檔案系統解釋。
7 、檢測虛擬結構是否正確,如不正確,重複 4-7 過程。
8 、確定資料無誤後,按使用者要求回遷資料。如果仍然使用原盤,需確定已經完全對原盤做過備份後,重建 RAID ,再做回遷。回遷作業系統時,可以使用 linux livecd 或 win pe( 通常不支援 ) 等進行,也可以在故障伺服器上用另外硬碟安裝一個回遷用的作業系統,再進行扇區級別的回遷。
9 、資料移交後,由我資料恢復中心延長保管資料 3 天,以避免可能忽略的紕漏。
【預估週期】
備份時間:2 小時左右
解釋及匯出資料時間:約4 小時
回遷作業系統:約4 小時。
【過程詳解】
1 、對原硬碟進行完整映象,映象後發現 2 號盤有 10-20 個壞扇區,其餘磁碟均無壞道。
2 、透過對結構的分析得到的最佳結構為 0,1,2,3 盤序,缺 3 號盤,塊大小 512 扇區, backward parity(Adaptec) ,結構如下圖:
3 、組好後資料驗證, 200M 以上的最新壓縮包解壓無報錯,確定結構正確。
4 、直接按此結構生成虛擬 RAID 到一塊單硬碟上,開啟檔案系統無明顯報錯。
5 、確定備份包安全的情況下,經客戶同意後,對原盤重建 RAID ,重建時已經用全新硬碟更換損壞的 2 號盤。將恢復好的單盤用 USB 方式接入故障伺服器,再用 linux SystemRescueCd 啟動故障伺服器,之後透過 dd 命令進行全盤迴寫。
6 、回寫後,啟動作業系統。
7 、 dd 所有資料後,啟動作業系統,無法進入,報錯資訊為: /etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied ,分析為此檔案許可權有問題。
8 、用 SystemRescueCd 重啟後檢查,此檔案時間、許可權、大小均有明顯錯誤,顯然節點損壞。
9 、重新分析重組資料中的根分割槽,定位出錯的 /sbin/pidof ,發現問題因 2 號盤壞道引起。
10 、使用 0 , 1 , 3 這 3 塊盤,針對 2 號盤的損壞區域進行 xor 補齊。補齊後重新校驗檔案系統,依然有錯誤,再次檢查 inode 表,發現 2 號盤損壞區域有部分節點表現為 ( 圖中的 55 55 55 部分 ) :
11 、很明顯,雖然節點中描述的 uid 還正常存在,但屬性,大小,以最初的分配塊全部是錯誤的。按照所有可能進行分析,確定無任何辦法找回此損壞節點。只能希望修復此節點,或複製一個相同的檔案過來。對所有可能有錯的檔案,均透過日誌確定原節點塊的節點資訊,再做修正。
12 、修正後重新 dd 根分割槽,執行 fsck -fn /dev/sda5 ,進行檢測,依然有報錯,如下圖:
13 、根據提示,在系統中發現有多個節點共用同樣的資料塊。按此提示進行底層分析,發現,因 3 號盤早掉線,幫存在節點資訊的新舊交集。
14 、按節點所屬的檔案進行區別,清除錯誤節點後,再次執行 fsck -fn /dev/sda5, 依然有報錯資訊,但已經很少。根據提示,發現這些節點多位於 doc 目錄下,不影響系統啟動,於是直接 fsck -fy /dev/sda5 強行修復。
15 、修復後,重啟系統,成功進入桌面。啟動資料庫服務,啟動應用軟體,一切正常,無報錯。
到此,資料恢復及系統回遷工作完成。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2662891/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 伺服器資料恢復-RAID5常見故障的資料恢復方案伺服器資料恢復AI
- 【伺服器資料恢復】某品牌x3850伺服器RAID5資料恢復案例伺服器資料恢復AI
- 【北亞資料恢復】IBM3650伺服器raid5故障硬碟離線的資料恢復案例資料恢復IBM伺服器AI硬碟
- IBM X3850伺服器崩潰資料恢復過程記錄IBM伺服器資料恢復
- 【伺服器資料恢復】IBM儲存raid5故障導致卷無法掛載的資料恢復伺服器資料恢復IBMAI
- IBM X3850伺服器誤刪虛擬機器後如何恢復資料IBM伺服器虛擬機
- raid5常見故障資料恢復方法/伺服器資料恢復常用方法AI資料恢復伺服器
- 伺服器資料恢復—不同型號伺服器RAID5故障的資料恢復案例伺服器資料恢復AI
- 【北亞伺服器資料恢復】IBM DS系列儲存硬碟故障導致RAID5崩潰的資料恢復伺服器資料恢復IBM硬碟AI
- 【伺服器資料恢復】IBM某型號儲存RAID5資料恢復案例伺服器資料恢復IBMAI
- 【伺服器資料恢復】IBM某型號伺服器RAID5磁碟陣列資料恢復案例伺服器資料恢復IBMAI陣列
- Raid5磁碟陣列資料恢復成功案例/伺服器資料恢復方案AI陣列資料恢復伺服器
- 【伺服器資料恢復】xen server常見故障的資料恢復方案伺服器資料恢復Server
- raid5硬碟故障資料恢復過程AI硬碟資料恢復
- Oracle 不同故障的恢復方案Oracle
- 【伺服器資料恢復】磁碟物理故障導致RAID5崩潰的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】VMFS檔案系統RAID5硬碟故障的資料恢復案例伺服器資料恢復AI硬碟
- 伺服器raid5陣列故障排查及資料恢復方法篇伺服器AI陣列資料恢復
- 【伺服器資料恢復】磁碟壞道故障導致RAID5崩潰的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid5磁碟陣列磁碟出現故障離線的資料恢復案例伺服器資料恢復AI陣列
- 【伺服器資料恢復】raid5故障導致上層應用崩潰的資料恢復案例伺服器資料恢復AI應用崩潰
- IBM伺服器raid5兩塊硬碟離線資料恢復過程IBM伺服器AI硬碟資料恢復
- IBM伺服器資料恢復IBM伺服器資料恢復
- 【伺服器資料恢復】RAID5崩潰後強制上線導致故障的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid5故障導致儲存的卷無法掛載的資料恢復伺服器資料恢復AI
- 伺服器資料恢復—EMC儲存zfs檔案系統下raid5故障的資料恢復案例伺服器資料恢復AI
- IBM X3650伺服器系統損壞故障的資料恢復IBM伺服器資料恢復
- 解析ESX SERVER故障資料恢復方法Server資料恢復
- 【伺服器資料恢復】DELL PowerEdge伺服器RAID5資料恢復案例伺服器資料恢復AI
- 【北亞資料恢復】IBM DS系列儲存伺服器硬碟故障、對映出錯的資料恢復資料恢復IBM伺服器硬碟
- linux伺服器資料恢復方法_伺服器硬碟故障解決方案Linux伺服器資料恢復硬碟
- 【北亞資料恢復】HP P2000伺服器 RAID5硬碟故障掉線的資料恢復資料恢復伺服器AI硬碟
- 【伺服器資料恢復】xen server儲存庫(sr)常見故障的資料恢復方案伺服器資料恢復Server
- 【伺服器資料恢復】Raid磁碟陣列常見故障解析伺服器資料恢復AI陣列
- 【伺服器資料恢復】IBM X系列伺服器資料恢復案例伺服器資料恢復IBM
- 恢復伺服器故障硬碟的資料伺服器硬碟
- Oracle ASM故障資料恢復解決方案OracleASM資料恢復