企業級儲存 虛擬化 Vsphere NFS救援案例(2)

Posted on Posted in 硬體
報告單6TB

這邊再來分享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 .

image

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位置  ) 一大段的明碼區可以幫助我們再確定是否校驗正確

image

再看一次Raid 結構圖  Stripe size=128 Sectors  
在一大段明文中 是最簡易判定Raid 是否有錯誤. 有錯誤就會有亂碼 

我們跳躍大概12個 Stripe size =1536 sector  
Winhex 選Go To Offset

image

 

發現這邊也是明文 .上下捲動 到前面原先扇區 發現全部都是明文 沒有任何亂碼

image

可以看到明碼的英文,證明這段RAID 的排序跟方向Stripe size 正確 

這時候開始考驗硬體了. 組合所有 Raid 
轉成超大鏡像檔案

上次iSCSI虛擬化救援案例有提到 會有三種狀況.

  1. 整個iSCSI Lun都還可mount ,裡面的 分區跟FS (VMDK檔案也都正常 )
  2. iSCSI Lun 文件系統大體完整或可救、重要的VM 檔案都還在、檔名也正常,  VM還可正常Boot
  3. 前二種都無法成功,只能用Raw Recovery 技術撈出 VMDK裡的檔案 ,能拿回多少就多少

本次ext 4+NFS 案例 由於大量Rebuild狀況. ext 4 文件系統都已經毀了.
因此只能使用 File Carving (Raw recovery)手段來做整個分區與虛擬化檔案救援.

方法為
先將所有硬碟生成一個超大Raid dd鏡像檔案
再用自行編寫File carving程式將檔案恢復… (使用此技術會有一定風險檔案打不開)

碎片恢復成果:
虛擬機檔案無法恢復.
但碎片恢復:如Office 文件 , MOV,照片檔案部份都可以正常打開 (因為保護客戶所以打馬賽克)

 

試著打開 office文件 , mov 文件.都可正常打開

 

 

 

這次案例完整性不如上次良好 其實原因都在於客戶做太多破壞性的操作 

遇到企業儲存損壞
必須要在 上線時間, 備份檔完整度 ,處理方法. 成本做一個取捨 .
當資料真正重要時自己或是找委外廠商(如OSSLab)先低成本備份鏡像.
再給系統整合廠商或是NAS FAE 處理
在處理不行時候 再交給資料救援廠商.這也是一個作法

瞭解真正技術運作原理 就會知道怎樣在最合理成本下去規避風險 取得平衡

 

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *