【伺服器資料恢復】某品牌StorageWorks伺服器raid資料恢復案例
伺服器資料恢復環境:
某品牌StorageWorks伺服器;
8塊SAS硬碟組成raid5,一塊熱備盤。
伺服器故障:
伺服器執行過程中有兩塊硬碟先後離線,伺服器癱瘓,lun無法正常使用。伺服器管理員聯絡我們資料恢復中心進行資料恢復。
我們資料恢復中心的伺服器資料恢復工程師對伺服器中所有磁碟進行物理檢測和壞道檢測,沒有發現問題。
伺服器資料恢復流程:
1、對故障伺服器所有硬碟做映象,以防在資料恢復過程中對原始資料造成二次破壞。
備份的部分資料如下圖:
2、伺服器故障原因分析:
目前初步瞭解的情況為基於RAID組的LUN有6個,均分配給HP-Unix小機使用,上層做的LVM邏輯卷,重要資料為Oracle
資料庫及OA服務端。一旦故障伺服器中的某些磁碟效能不穩定,該型號伺服器中的控制器會將其認為是壞盤的磁碟踢出
RAID組。而一旦RAID組中掉線的盤達到RAID級別允許掉盤的極限,那麼這個RAID將不可用,伺服器癱瘓。
3、分析伺服器RAID組結構:
伺服器的LUN都是基於RAID組的,要想恢復伺服器資料就需要先分析底層RAID組的資訊,然後根據分析的資訊重構原始的
RAID組。伺服器資料恢復工程師分析所有硬碟後發現4號盤的資料同其他盤不太一樣,初步認為是hot Spare盤。接著分析
其他資料盤,分析Oracle資料庫頁在每個磁碟中分佈的情況,並根據資料分佈的情況獲取到
RAID組的條帶大小,磁碟順序及資料走向等RAID組的重要資訊。
4、分析伺服器RAID組掉線盤:
根據上述分析的RAID資訊,通過北亞自主開發的RAID虛擬重組程式將原始的RAID組虛擬出來。但由於整個RAID組中一共
掉線兩塊盤,因此需要分析這兩塊硬碟掉線的順序。仔細分析每一塊硬碟資料,發現有一塊硬碟在同一個條帶上的資料和其
他硬碟明顯不一樣,因此初步判斷此硬碟可能是最先掉線的,通過北亞自主開發的RAID校驗程式對這個條帶做校驗,最終
確定最先掉線的硬碟。
5、分析RAID組中的LUN資訊:
由於LUN是基於RAID組的,因此需要根據上述分析的資訊將RAID組最新的狀態虛擬出來,然後分析LUN在RAID組中的分配
情況,以及LUN分配的資料塊MAP。由於底層有6個LUN,因此只需要將每一個LUN的資料塊分佈MAP提取出來,然後針對這
些資訊編寫相應的程式,對所有LUN的資料MAP做解析,然後根據資料MAP匯出所有LUN的資料。
匯出的資料如下圖:
6、伺服器LVM邏輯卷及VXFS檔案系統修復:
伺服器資料恢復工程師分析所有生成出來的LUN,發現所有LUN中均包含HP-Unix的LVM邏輯卷資訊。資料恢復工程師嘗試
解析每個LUN中的LVM資訊,發現一共有三套LVM:45G的LVM中劃分了一個LV,存放OA伺服器端的資料;190G的LVM中
劃分了一個LV,存放臨時備份資料;剩餘4個LUN組成一個2.1T左右的LVM,劃分了一個LV,存放Oracle資料庫檔案。
伺服器資料恢復工程師編寫解釋LVM的程式,嘗試將每套LVM中的LV卷都解釋出來,但發現解釋程式出錯。仔細分析程式報
錯的原因,開發工程師debug程式出錯的位置,檔案系統工程師對恢復的LUN做檢測,檢測LVM資訊是否會因儲存癱瘓導致
LMV邏輯卷的資訊損壞。經過檢測發現確實因為儲存癱瘓導致LVM資訊損壞。
嘗試人工對損壞的區域進行修復,並同步修改程式,重新解析LVM邏輯卷。
搭建HP-Unix環境,將解釋出來的LV卷對映到HP-Unix,並嘗試Mount檔案系統,結果Mount檔案系統出錯。嘗試使用
“fsck –F vxfs”命令修復vxfs檔案系統,修復後還是不能掛載。懷疑底層vxfs檔案系統的部分後設資料可能破壞,需要進行手
工修復。
仔細分析解析出來的LV,並根據VXFS檔案系統的底層結構校驗此檔案系統是否完整。分析發現底層VXFS檔案系統果然有問
題,原來儲存癱瘓的同時此檔案系統正在執行IO操作,因此導致部分檔案系統元檔案沒有更新和損壞。資料恢復工程師對這
些損壞的元檔案進行手工修復,保證VXFS檔案系統能夠正常解析。再次將修復好的LV卷掛載到HP-Unix小機上,嘗試Mount
檔案系統,檔案系統沒有報錯,成功掛載。
7、檢測Oracle資料庫檔案並啟動資料庫:
在HP-Unix機器上mount檔案系統後,將所有使用者資料均備份至指定磁碟空間。所有使用者資料大小在1.2TB左右。
部分檔案目錄截圖如下:
使用Oracle資料庫檔案檢測工具檢測每個資料庫檔案是否完整,沒有發現錯誤。使用北亞自主研發的Oracle資料庫檢測工具
檢測,發現部分資料庫檔案和日誌檔案校驗不一致,資料庫資料恢復工程師對此類檔案進行修復並校驗,直到所有檔案校驗
均完全通過。
將恢復出來的Oracle資料庫附加到原始生產環境的HP-Unix伺服器中,嘗試啟動Oracle資料庫,Oracle資料庫啟動成功。
8、啟動Oracle資料庫,啟動OA服務端,在本地電腦上安裝OA客戶端。通過OA客戶端對最新的資料記錄以及歷史資料記錄
進行驗證,並且有安排不同部門人員進行遠端驗證。最終資料驗證無誤,資料完整,資料恢復成功。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2904606/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【伺服器資料恢復】某品牌伺服器儲存raid5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】某品牌x3850伺服器RAID5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】某品牌MSA SAN儲存資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】EMC某型號伺服器raid5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid0資料恢復案例&raid資料回遷案例伺服器資料恢復AI
- 【伺服器raid資料恢復】光纖儲存raid資料恢復案例伺服器AI資料恢復
- 【伺服器資料恢復】華為某型號伺服器raid6資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】某醫院儲存伺服器RAID5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】戴爾某型號伺服器raid故障的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】某網站伺服器資料恢復案例伺服器資料恢復網站
- 【伺服器資料恢復】某雲ECS伺服器資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】伺服器RAID0+1資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】IBM某型號儲存RAID5資料恢復案例伺服器資料恢復IBMAI
- 【伺服器資料恢復】某研究院DELL伺服器中RAID5資料恢復案例伺服器資料恢復AI
- 伺服器資料恢復案例之RAID資訊丟失資料恢復伺服器資料恢復AI
- 【伺服器資料恢復】DELL PowerEdge伺服器RAID5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】IBM某型號伺服器RAID5磁碟陣列資料恢復案例伺服器資料恢復IBMAI陣列
- 【伺服器資料恢復】某品牌V7000儲存裝置資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】某品牌ProLiant伺服器raid癱瘓資料庫檔案損壞的資料恢復伺服器資料恢復AI資料庫
- 【伺服器資料恢復】Vsan資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】某銀行伺服器崩潰的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】伺服器硬碟資料恢復案例伺服器資料恢復硬碟
- 伺服器資料恢復-2盤raid0陣列資料恢復案例伺服器資料恢復AI陣列
- 【伺服器資料恢復】Storwize系列儲存raid5資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid5硬碟離線的資料恢復案例伺服器資料恢復AI硬碟
- 【伺服器資料恢復】惠普伺服器raid5崩潰的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】HP伺服器Raid5磁碟陣列資料恢復案例伺服器資料恢復AI陣列
- 【伺服器資料恢復】伺服器RAID0的RAID資訊被破壞的資料恢復案例伺服器資料恢復AI
- 【伺服器raid資料恢復】RAID5兩塊盤離線的資料恢復案例伺服器AI資料恢復
- 伺服器資料恢復-ESX SERVER資料恢復案例伺服器資料恢復Server
- 【伺服器資料恢復】SUN SOLARIS資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】HP StorageWorks系列儲存RAID5兩塊盤離線的資料恢復伺服器資料恢復AI
- 伺服器資料恢復—不同型號伺服器RAID5故障的資料恢復案例伺服器資料恢復AI
- 【北亞伺服器資料恢復】Infortrend ESDS系列伺服器raid6資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】PowerEdge伺服器REDHAT系統下RAID5資料恢復案例伺服器資料恢復RedhatAI
- 伺服器資料恢復成功案例+伺服器資料恢復原理伺服器資料恢復
- 伺服器磁碟陣列資料恢復,raid資料恢復方法伺服器陣列資料恢復AI