某公司資料恢復報告書

2021-09-03 04:08:35 字數 4122 閱讀 2663

一、故障描述

1、裝置清單

裝置名稱

裝置型號

數量hp fc

儲存hp msa2000

1450g sas.硬碟8

2、故障描述

整個儲存空間由8塊450gb sas的硬碟組成,其中7塊硬碟組成乙個raid5的陣列,剩餘1塊做成熱備盤使用。由於raid5陣列中出現2塊硬碟損壞,而此時只有一塊熱備盤成功啟用,因此導致raid5陣列癱瘓,上層lun無法正常使用。

二、檢測磁碟

由於儲存是因為raid陣列中某些磁碟掉線,從而導致整個儲存不可用。因此接收到磁碟後先對所有磁碟做物理檢測,檢測完後發現沒有物理故障。接著使用壞道檢測工具檢測磁碟壞道,發現也沒有壞道。磁碟壞道檢測日誌如下圖:

三、備份資料

考慮到資料的安全性以及可還原性,在做資料恢復之前需要對所有源資料做備份,以防其他原因導致資料無法再次恢復。使用dd命令或winhex工具將所有磁碟都映象成檔案。備份完部分資料如下圖:

四、故障分析

1、分析故障原因

由於前兩個步驟並沒有檢測到磁碟有物理故障或者是壞道,由此推斷可能是由於某些磁碟讀寫不穩定導致故障發生。因為hp msa2000控制器檢查磁碟的策略很嚴格,一旦某些磁碟效能不穩定,hp msa2000控制器就認為是壞盤,就將認為是壞盤的磁碟踢出raid組。而一旦raid組中掉線的盤到達到raid級別允許掉盤的極限,那麼這個raid組將變的不可用,上層基於raid組的lun也將變的不可用。目前初步了解的情況為raid組的lun有6個,均分配給hp-unix小機使用,上層做的lvm邏輯卷,重要資料為oracle資料庫及oa服務端。

2、分析raid組結構

hp msa2000儲存的lun都是基於raid組的,因此需要先分析底層raid組的資訊,然後根據分析的資訊重構原始的raid組。分析每一塊資料盤,發現4號盤的資料同其它資料盤不太一樣,初步認為可能是hot spare盤。接著分析其他資料盤,分析oracle資料庫頁在每個磁碟中分布的情況,並根據資料分布的情況得出raid組的條帶大小,磁碟順序及資料走向等raid組的重要資訊。

3、分析raid組掉線盤

根據上述分析的raid資訊,嘗試通過北亞自主開發的raid虛擬程式將原始的raid組虛擬出來。但由於整個raid組中一共掉線兩塊盤,因此需要分析這兩塊硬碟掉線的順序。仔細分析每一塊硬碟中的資料,發現有一塊硬碟在同乙個條帶上的資料和其他硬碟明顯不一樣,因此初步判斷此硬碟可能是最先掉線的,通過北亞自主開發的raid校驗程式對這個條帶做校驗,發現除掉剛才分析的那塊硬碟得出的資料是最好的,因此可以明確最先掉線的硬碟了。

4、分析raid組中的lun資訊

由於lun是基於raid組的,因此需要根據上述分析的資訊將raid組最新的狀態虛擬出來。然後分析lun在raid組中的分配情況,以及lun分配的資料塊map。底層有6個lun,因此只需要將每乙個lun的資料塊分布map提取出來。然後針對這些資訊編寫相應的程式,對所有lun的資料map做解析,然後根據資料map並匯出所有lun的資料。

五、lvm邏輯捲及vxfs檔案系統修復

1、解析lvm邏輯卷

分析生成出來的所有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卷都解發布來,但發現解釋程式出錯。

2、修復lvm邏輯卷

仔細分析程式報錯的原因,安排開發工程師debug程式出錯的位置,並同時安排高階檔案系統工程師對恢復的lun做檢測,檢測lvm資訊是否會因儲存癱瘓導致lvm邏輯卷的資訊損壞。經過仔細檢測,發現確實因為儲存癱瘓導致lvm資訊損壞。嘗試人工對損壞的區域進行修復,並同步修改程式,重新解析lvm邏輯卷。

3、解析vxfs檔案系統

搭建hp-unix環境,將解發布來的lv卷對映到hp-unix,並嘗試mount檔案系統。結果mount檔案系統出錯,嘗試使用「fsck –f vxfs」 命令修復vxfs檔案系統,但修復結果還是不能掛載,懷疑底層vxfs檔案系統的部分源資料可能被破壞,需要進行手工修復。

4、修復vxfs檔案系統

仔細分析解析出來的lv,並根據vxfs檔案系統的底層結構校驗此檔案系統是否完整。分析發現底層vxfs檔案系統果然有問題,原來當時儲存癱瘓的同時此檔案在系統正在執行io操作,因此導致部分檔案系統原始檔沒有更新以及損壞。人工對這些損壞的原始檔進行手工修復,保證vxfs檔案系統能夠正常解析。再次將修復好的lv卷掛載到hp-unix小機上,嘗試mount檔案系統,檔案系統沒有報錯,成功掛載。

六、檢測oracle資料庫檔案並啟動資料庫

1、恢復所有使用者檔案

在hp-unix機器上mount檔案系統後,將所有使用者資料均備份至指定磁碟空間。所有使用者資料大小在1.2tb左右。部分檔案目錄截圖如下:

2、檢測資料庫檔案是否完整

使用oracle資料庫檔案檢測工具「dbv」檢測每個資料庫檔案是否完整,發現並沒有錯誤。再使用北亞自主研發的oracle資料庫檢測工具(檢驗更嚴格),發現有部分資料庫檔案和日誌檔案校驗不一致,安排高階資料庫工程師對此類檔案進行修復,並再次校驗,直到所有檔案校驗均完全通過。

3、啟動oracle資料庫

由於我們提供的hp-unix環境沒有此版本的oracle資料,因此和使用者協調將原始生成環境帶至北亞資料恢復中心,然後將恢復的oracle資料庫附加到原始生產環境的hp-unix伺服器中,嘗試啟動oracle資料庫,oracle資料庫啟動成功。部分截圖如下:

七、資料驗證

由使用者方配合,啟動oracle資料庫,啟動oa服務端,在本地筆記本安裝oa客戶端。通過oa客戶端對最新的資料記錄以及歷史資料記錄進行驗證,並且有使用者安排遠端不同部門人員進行遠端驗證。最終資料驗證無誤,資料完整,資料恢復成功。

八、移交資料

使用者方重新購買了8塊hp-msa2000原廠硬碟,由北亞工程師配合重新對hp-msa2000儲存進行配置。建立和原始一樣的volume,並將恢復的資料全部複製到重新配置好的儲存中,並驗證所有服務能夠正常啟動,包括oracle資料庫服務,oa服務端等。

九、資料恢復結論

由於故障發生後儲存現場環境良好,沒做相關危險的操作,對後期的資料恢復有很大的幫助。整個資料恢復過程中雖然遇到好多技術瓶頸,但也都一一解決。最終在預期的時間內完成整個資料恢復,恢復的資料使用者方也相當滿意。

十、專案成員列表

工程師姓名

**郵箱

商務張曉娜

185,

1528

,3863

zxn#frombyte.com

專案主管

鄧奇185

,1528

,3878

dq#frombyte.com

儲存工程師

鄧奇185

,1528

,3878

dq#frombyte.com

raid

工程宋國建

185,

1528

,3861

songguojian#frombyte.com

開發工程師

秦穎吉185

,1528

,3871

qyj#frombyte.com

檔案系統工程師

宋國建185

,1528

,3861

songguojian#frombyte.com

審核工程師

張宇 工程師職能:

商務工程師:負責反饋訊息給使用者

初檢工程師:負責裝置初檢事宜

實施工程師:負責裝置資料安全救援事宜

審核工程師:負責每一步流程審核

某公司資料恢復報告書

一 故障描述 1 裝置清單 2 故障描述 整個儲存空間由8塊450gb sas的硬碟組成,其中7塊硬碟組成乙個raid5的陣列,剩餘1塊做成熱備盤使用。由於raid5陣列中出現2塊硬碟損壞,而此時只有一塊熱備盤成功啟用,因此導致raid5陣列癱瘓,上層lun無法正常使用。二 檢測磁碟 由於儲存是因為...

某公司資料恢復報告書

一 故障描述 1 裝置清單 裝置名稱 裝置型號 數量hp fc 儲存hp msa2000 1450g sas.硬碟8 2 故障描述 整個儲存空間由8塊450gb sas的硬碟組成,其中7塊硬碟組成乙個raid5的陣列,剩餘1塊做成熱備盤使用。由於raid5陣列中出現2塊硬碟損壞,而此時只有一塊熱備盤...

某公司資料恢復報告書

一 故障描述 1 裝置清單 裝置名稱 裝置型號 數量 hp fc儲存 hp msa2000 1 450g sas.硬碟 8 2 故障描述 整個儲存空間由8塊450gb sas的硬碟組成,其中7塊硬碟組成乙個raid5的陣列,剩餘1塊做成熱備盤使用。由於raid5陣列 現2塊硬碟損壞,而此時只有一塊熱...