【伺服器資料恢復】磁碟物理故障導致RAID5崩潰的資料恢復案例
伺服器資料恢復環境&故障:
某品牌StorageWorks儲存裝置,8塊磁碟組建一組raid5磁碟陣列。儲存中2塊磁碟掉線導致陣列崩潰,經過檢查發現掉線
的2塊磁碟均存在物理故障。
伺服器資料恢復過程:
1、硬體工程師對掉線的兩塊磁碟進行檢測,加電後磁頭無法尋道,分離PCB並清潔HDA元件後再次嘗試加電,磁頭依然無
法尋道,需要進行物理修復。經過複雜的修復過程(此處略過)後2塊故障硬碟可以正常識別。
2、將故障儲存內所有磁碟以只讀方式進行映象備份,後續資料分析和資料恢復操作都基於映象檔案進行,避免在恢復資料
的過程中對原始資料造成二次破壞。
3、基於映象檔案分析故障儲存裝置中硬碟的底層資料,發現所有磁碟的0扇區出現了“55 AA”(0x01C2H處表示該分割槽的
型別,顯示“05”就表示這是一個擴充套件分割槽,從0扇區看這是一個不正常的 MBR 分割槽結構)。7號盤和8號盤的0扇區也找到
了“55 AA”的標誌。8號硬碟是一個正常的MBR分割槽,
其0x01C6處的數值代表指向的下一個扇區為GPT的頭部。
7號硬碟0x01C6處的數值代表指向下一個扇區,但是下一個扇區很明顯不是GPT的頭部。
透過上面的分析,北亞企安資料恢復工程師初步判斷陣列中的8號盤和7號盤分別為第一塊和最後一塊硬碟,GPT分割槽所在扇
區起始於172032扇區,因此初步確定LUN的起始扇區是172032扇區。
4、經過分析raid確定了條帶大小為1024個扇區。按照1024扇區進行分割,使一個記錄為一個條帶的大小。
5、當7塊盤都定位到同一位置時,透過對比可以判斷校驗區的走向,繼而判斷整個RAID5的走向。之前已經判斷出8號盤是
第一塊盤了,把8號盤放在第一個位置,確定RAID5的走向和盤序。
6、上面已經初步確定了LUN的起始扇區是172032扇區,跳轉到172032扇區進行觀察,正常情況下這個扇區所屬條帶中的5
號盤應該是校驗區,但實際顯示校驗區為8號盤。根據該raid左走向的規律,5號盤的校驗區應該在172032-1024=171008扇
區,即上一個條帶。跳轉到171008扇區,發現校驗區為5號盤。因此可以確定LUN的起始扇區為171008扇區。
7、根據上面步驟中獲取到的raid相關資訊使用工具重組raid。
8、由於資料從1024*8=8192個扇區開始,剛組好的RAID必須和一個檔案再進行一次重組操作。RAID的起始扇區
(Start sectors)選擇8192,這個檔案可以任意選擇起始扇區和大小(Count sectors),下圖為重組後的raid5磁碟陣列。
資料驗證:
RAID5磁碟陣列重建完成後由使用者方工程師進行驗證,經過反覆驗證確認恢復資料完整有效,本次資料恢復工作完成。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2949944/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【伺服器資料恢復】磁碟壞道故障導致RAID5崩潰的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid5故障導致上層應用崩潰的資料恢復案例伺服器資料恢復AI應用崩潰
- 【伺服器資料恢復】RAID5崩潰後強制上線導致故障的資料恢復案例伺服器資料恢復AI
- 伺服器資料恢復-伺服器磁碟被踢導致陣列崩潰的RAID5資料恢復案例伺服器資料恢復陣列AI
- 【北亞資料恢復案例】raid0硬碟故障導致伺服器崩潰的資料恢復資料恢復AI硬碟伺服器
- 【伺服器資料恢復】raid5硬碟離線導致EVA儲存崩潰資料恢復案例伺服器資料恢復AI硬碟
- 【伺服器資料恢復】RAID5崩潰導致上層OA不可用的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】惠普伺服器raid5崩潰的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】RAID5崩潰後強制上線導致資料丟失的資料恢復案例伺服器資料恢復AI
- 【北亞伺服器資料恢復】IBM DS系列儲存硬碟故障導致RAID5崩潰的資料恢復伺服器資料恢復IBM硬碟AI
- 【伺服器資料恢復】EMC儲存raid5崩潰的資料恢復案例伺服器資料恢復AI
- 伺服器磁碟離線導致RAIDZ崩潰資料恢復伺服器AI資料恢復
- 【北亞伺服器資料恢復】RAIDZ多塊磁碟離線導致伺服器崩潰的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】意外斷電導致linux伺服器崩潰的資料恢復案例伺服器資料恢復Linux
- 【北亞企安資料恢復】RAIDZ多塊磁碟離線導致崩潰的資料恢復案例資料恢復AI
- 【伺服器資料恢復】伺服器進水導致伺服器崩潰的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】同友儲存raid5崩潰的資料恢復案例伺服器資料恢復AI
- 伺服器資料恢復—raid5磁碟離線導致SAP資料丟失的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】RAID5崩潰後強制上線導致檔案丟失的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid6崩潰導致分割槽丟失的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】離線硬碟強制上線導致RAID5崩潰的資料恢復伺服器資料恢復硬碟AI
- 【伺服器資料恢復】REISERFS檔案系統RAID5崩潰的資料恢復案例伺服器資料恢復AI
- 伺服器資料恢復—VMware下誤重灌系統導致伺服器崩潰的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】raid5崩潰導致lvm資訊和VXFS檔案系統損壞的資料恢復案例伺服器資料恢復AILVM
- 伺服器資料恢復-raid5多塊磁碟離線,熱備盤沒有啟用導致陣列崩潰的資料恢復案例伺服器資料恢復AI陣列
- 【北亞伺服器資料恢復】raid5崩潰導致同友儲存無法啟動的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】硬碟離線但是熱備盤未啟用導致RAID5崩潰的資料恢復案例伺服器資料恢復硬碟AI
- 伺服器資料恢復—V7000儲存磁碟故障導致Mdisk失效的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】raid5磁碟陣列磁碟出現故障離線的資料恢復案例伺服器資料恢復AI陣列
- 儲存崩潰資料恢復過程;資料恢復案例資料恢復
- 【伺服器資料恢復】某銀行伺服器崩潰的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】RAID6中3塊磁碟離線崩潰的資料恢復案例伺服器資料恢復AI
- 【儲存資料恢復】儲存上的raid5陣列崩潰的資料恢復案例資料恢復AI陣列
- 伺服器資料恢復-V7000儲存磁碟故障導致業務中斷的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】raid5資料恢復案例伺服器資料恢復AI
- 【儲存資料恢復】EMC某型號儲存raid5崩潰的資料恢復案例資料恢復AI
- 伺服器資料恢復-伺服器崩潰導致銀行業務模組不可用的資料恢復案例伺服器資料恢復行業
- 【伺服器資料恢復】硬碟壞道和不穩定扇區導致伺服器崩潰的資料恢復案例伺服器資料恢復硬碟