一、故障描述
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塊硬碟損壞，而此時只有一塊熱...