報告單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 ,裡面的 分區跟檔案系統 ,裡面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 處理
在處理不行時候 再交給資料救援廠商.這也是一個作法

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

 

留言

留言