was successfully added to your cart.
虛擬化

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

By 2017-04-07 3 Comments
前面的虛擬化救援案例 
虛擬化救援案例 (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 ) 還是沒有資料
 
第二路 
用”肉眼跟大腦”根據檔案系統 算出   硬碟陣列排序  (Strip size 應該為1024KByte) 
 
 
組合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

 
VM匯入看似成功 不過有報錯

 
 
 
 開機執行報錯
 
這時就要思考 這些快照檔連續性問題了…
 
2 .轉換與修復 快照檔 
這邊看看有沒有辦法將快照檔轉成Flat檔 並且做檔案檢查
http://www.vmware.com/pdf/VirtualDiskManager.pdf

vmware-vdiskmanager -R 快照索引檔vmdk  修復快照檔
vmware-vdiskmanager -r 快照索引檔vmdk -t 0 目標flat快照檔
使用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實驗室 .
直接有效在短時時間搶救恢復客戶所要數據.

Thx Chang

Author Thx Chang

More posts by Thx Chang

Join the discussion 3 Comments

Leave a Reply