這邊再來分享OSSLab 虛擬化儲存救援狀況
客戶原始架構
Vsphere 5.x ,Synology NAS .6TB *3 (發生的狀況如下 )
1. 硬碟一直離線又強制上線 不同顆 並且疑似有 Rebuild
2.一開始可以Mount 後來連Mount都沒辦法.
3.一樣也是找了Synology公司 FAE處理 再找SI.都無法解決問題
此案例不同於前案例 .客戶有可能做了大量Rebuild ,
並且由於客戶非常狀況外. 其實連原始設定都不知道.
處理這種案例 最重要的第一步 必須必備超大型的儲存Storage .
為了安全起見 如果需要做 Rebuild ,fsck 動作 全扇區備份一份是一定要的.這會吃掉一份空間
為了組合 Raid img 又一份 空間
為了倒出資料 又一份空間
這案例 目前還用不到做Rebuild ,fsck 狀況 .因此資料量約 2倍就可..
大體上 準備30TB 空間是必備的 .
如果一間資料恢復公司 沒有這些空閒超大儲存空間 .
是無法在最快時間與安全的救援大型Stroage .
NFS 虛擬化架構,其實會很單純的VMDK檔案放在ext 4 檔案系統上. 要先組好Raid Block Device.
因為有過Rebuild 要先修復ext 4檔案系統，再拉出裡面的虛擬化檔案.
Rebuild 也有可能破壞到虛擬化格式檔案.
所以還要做虛擬機檔案格式修復.
更慘必須使用 File carving技術來取得檔案. 但是完整性會降低很多.
必須再三強調 rebuild 跟 fsck 都會造成很高的 資料恢復難度. 若資料重要 請先每顆硬碟都做全扇區備份.
但是照一般SI與NAS FAE流程就是先嘗試會這樣處理 (他們是免費的服務 不太可能處理太完整 )
分析Raid 5 結構
每顆硬碟前面分區為 NAS OS位置. 先取得真正DATA 區 偏移位置,
由於多次Mount 原有 MDADM Raid metadata 已經完全不正確…
剛好客戶客戶是用 thick provisioning我們藉由虛擬機內的 NTFS 的檔案系統的MFT 來分析出Raid 硬碟排列與Stripe size 大小. 判定出 64 Kbyte =128 Sectors Stripe size
排列方式如圖
客戶對 還是 hex 對?
把分析後的結果用Winhex組合後發現跟客戶說法完全不一樣!
客戶明明說是 3 顆Raid 5, 實際上發現應該是4顆raid 5 (missing 一顆)
在這種狀況下.
要針對整個Raid Storage 做 前 中 後 三個區段數據正確性分析.
因為做過Rebuild 前有可能跟中後段資料不一樣.
觀念上是所需要那區資料原來是怎樣就怎樣 就是最正確的
但整個跑下去非常耗時間…
但這邊有一個基本方法可以了解 我們先搜索一些DB常用英文單字 (select ,query,from )
搜索後 發現有一大段明文在位於 361 178 534 sector(約單硬碟180GB位置 ) 一大段的明碼區可以幫助我們再確定是否校驗正確
再看一次Raid 結構圖 Stripe size=128 Sectors
在一大段明文中 是最簡易判定Raid 是否有錯誤. 有錯誤就會有亂碼
我們跳躍大概12個 Stripe size =1536 sector
Winhex 選Go To Offset
發現這邊也是明文 .上下捲動 到前面原先扇區 發現全部都是明文 沒有任何亂碼
可以看到明碼的英文，證明這段RAID 的排序跟方向Stripe size 正確
這時候開始考驗硬體了. 組合所有 Raid
轉成超大鏡像檔案
上次iSCSI虛擬化救援案例有提到 會有三種狀況.
- 整個iSCSI Lun都還可mount ,裡面的 分區跟檔案系統 ,裡面VMDK都正常
- iSCSI Lun 文件系統大體完整或可救、重要的VM 檔案都還在、檔名也正常， VM還可正常Boot
- 前二種都無法成功，只能用Raw Recovery 技術撈出 VMDK裡的檔案 ，能拿回多少就多少
本次ext 4+NFS 案例 由於大量Rebuild狀況. ext 4 文件系統都已經毀了.
因此只能使用 File Carving (Raw recovery)手段來做整個分區與虛擬化檔案救援.
方法為
先將所有硬碟生成一個超大Raid dd鏡像檔案
再用自行編寫File carving程式將檔案恢復… (使用此技術會有一定風險檔案打不開)
碎片恢復成果:
虛擬機檔案無法恢復.
但碎片恢復:如Office 文件 , MOV,照片檔案部份都可以正常打開 （因為保護客戶所以打馬賽克）
試著打開 office文件 , mov 文件.都可正常打開
這次案例完整性不如上次良好 其實原因都在於客戶做太多破壞性的操作
遇到企業儲存損壞
必須要在 上線時間, 備份檔完整度 ,處理方法. 成本做一個取捨 .
當資料真正重要時自己或是找委外廠商(如OSSLab)先低成本備份鏡像．
再給系統整合廠商或是NAS FAE 處理
在處理不行時候 再交給資料救援廠商.這也是一個作法
瞭解真正技術運作原理 就會知道怎樣在最合理成本下去規避風險 取得平衡
