虛擬化救援案例 (3) 四天搶救服務器Raid與156個快照修復

前面的虛擬化救援案例 
虛擬化救援案例 (1) Vsphere 、Synology、iSCSI
虛擬化救援案例 (2) Vsphere 、NFS

在2017 三月清明連假前 4.1 PM:4:00
OSSLab 又接到客戶系統Server   4顆 300G SAS 硬碟 .Raid 5 . 虛擬化用vsphere 6 因為硬碟壞軌 ,硬碟 離線 0 , 3 (也不知離線時間前後順序) 
客戶表示好像快照到一半就掛了….. 

 
這邊最重要的就是 要替硬碟做鏡像先

SAS 壞軌硬碟要準備SAS等級資料救援設備.DD3000 .DD3000 設備可以做SAS硬碟斷電控制 SAS控制卡讀取.跟SAS Retry 

 

好的硬碟則使用我們全鏡像 Server .  15 bay  空bay 隨時待命,能讓所有客戶硬碟用最高速10GbE 網路傳到我們的服務器上。
才能在第一時間將客戶資料救援出來。

 

 

四個小時內 我們已經有全部硬碟的DD(鏡像)檔案 了 

 

 

客戶對於時效很急迫 因此我們在假期出動三個工程師 兵分二路同時進行  

法一.以原硬碟結構倒回陣列Server去 

 
將壞軌硬碟跟好的硬碟都 備份到新的硬碟上去   玩麻將四缺一遊戲

 

 

 

 

 
陣列卡選到 Foreign View Scan Foreign 想辦法匯入原陣列資料

注意這個方法 是用新鏡像的硬碟做的. 請不要去動原硬碟 並且我們有保留原硬碟DD鏡像

 

準備 USB Vsphere Boot 看看有沒有機會可mount 這Datastore ..
並沒有看到Datastore
 
到介面下這指令

Rescan Datastore (VMFS ) 還是沒有資料

 

 

 

組合Raid 生成總RAID 鏡像 

 

 

 

 找到VMFS分區.

 

 

客戶最重要資料是DB VM 但裡面竟然空的

 

我們分析過了  missing 2 硬碟 狀況下才有這目錄下的vmdk .(沒錯 必須要用離線硬碟 才會有正確資料)

 

 

 

 

但這時發現客戶做了15x個快照 XXXXXXX

 

 

 

這時候遇到麻煩了 …客戶要最新的資料 

解析VMDK快照 ,技術長說 他會解析. 他說七年前他沒解析成功 就會被市刑大抓進去了..
市刑大,Windows 2003, 虛擬化VMDK修複 – 酷!學園 – Study-Area

 技術長好不容易把157個 VMDK 指引一個個看完跟修正. 用SFTP 倒回去vsphere  .

發現連登錄VM都不行.

 

 

手動下指令註冊虛擬機  vim-cmd solo/registervm /vmfs/volumes/datastore_name/VM_directory/VM_name.vmx

 

 

 

 開機執行報錯

 

這時就要思考 這些快照檔連續性問題了…

 

2 .轉換與修復 快照檔 
這邊看看有沒有辦法將快照檔轉成Flat檔 並且做檔案檢查
http://www.vmware.com/pdf/VirtualDiskManager.pdf

使用vmware 工具 vmware vdiskmanger轉換快照檔為flat 第一個快照檔成功

 

 

轉換之後快照檔出現 Uncoveryable memory alloacation

之後換了不同版本 vmware vdiskmanger 與電腦都一樣錯誤訊息 . XXXXXXXXXXXXXXXXXXX

 

 

PANIC 當機!!!

 

來 換 vmkfstools  

vmkfstools -i XXXXX-000019.vmdk J880000019.vmdk -d thin 

 

DiskLib_Check() failed for source disk ‘XX-DB-000001.vmdk’: The specified feature is not supported by this version (24).

 

 

 

再次兵分二路計畫

A 組盡量修復 VM
B 組盡量能搞到最新版本快照內的mysql 撈給對方….
先Mount VMDK 吧.

 

VMware 官方Mount程式不吃 半損VMDK …>< 

 

 

寫一個小程式提取殘缺VMDK內資料..

 

 

 

Mysql 有報錯 但是還是先交給客戶了.. 

A 組盡量修復 VM
既然原廠工具不支持  自己寫了一個程式 修復快照 
超密技 述省略…..
VMX 也要修改  device 要轉向到修好的flat.vmdk

 

 

 

VM 可以開啟

 

完美Boot DB　都正常

 

 

 

 

我們在四個工作天左右 約99%恢復客戶在上面所有VM

結論

這個案件難度是非常高. 我們預估就算是VMWare 原廠Support 成功機率應該也低.

這案例能夠能夠成功救出來資料95%最大原因.
是因為客戶沒有先找其他廠商 .
其他廠商很有可能會先做了 rebuild 跟 fsck 都會造成很高的 資料恢復難度. 
而是選擇了OSSLab實驗室 .
直接有效在短時時間搶救恢復客戶所要數據.