前面的虛擬化救援案例
虛擬化救援案例 (1) Vsphere 、Synology、iSCSI
虛擬化救援案例 (2) Vsphere 、NFS在2017 三月清明連假前 4.1 PM:4:00
OSSLab 又接到客戶系統Server 4顆 300G SAS 硬碟 .Raid 5 . 虛擬化用vsphere 6 因為硬碟壞軌 ,硬碟 離線 0 , 3 (也不知離線時間前後順序)
客戶表示好像快照到一半就掛了…..
虛擬化救援案例 (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
到介面下這指令
並沒有看到Datastore
到介面下這指令
Rescan Datastore (VMFS ) 還是沒有資料
第二路
用”肉眼跟大腦”根據檔案系統 算出 硬碟陣列排序 (Strip size 應該為1024KByte)
組合Raid 生成總RAID 鏡像
找到VMFS分區.
客戶最重要資料是DB VM 但裡面竟然空的
我們分析過了 missing 2 硬碟 狀況下才有這目錄下的vmdk .(沒錯 必須要用離線硬碟 才會有正確資料)
但這時發現客戶做了15x個快照 XXXXXXX
這時候遇到麻煩了 …客戶要最新的資料
技術長好不容易把157個 VMDK 指引一個個看完跟修正. 用SFTP 倒回去vsphere .
發現連登錄VM都不行.
發現連登錄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 吧.
B 組盡量能搞到最新版本快照內的mysql 撈給對方….
先Mount VMDK 吧.
VMware 官方Mount程式不吃 半損VMDK …><
寫一個小程式提取殘缺VMDK內資料..
Mysql 有報錯 但是還是先交給客戶了..
A 組盡量修復 VM
既然原廠工具不支持 自己寫了一個程式 修復快照
超密技 述省略…..
VMX 也要修改 device 要轉向到修好的flat.vmdk
既然原廠工具不支持 自己寫了一個程式 修復快照
VMX 也要修改 device 要轉向到修好的flat.vmdk
VM 可以開啟
完美Boot DB 都正常
我們在四個工作天左右 約99%恢復客戶在上面所有VM結論
這個案件難度是非常高. 我們預估就算是VMWare 原廠Support 成功機率應該也低.
這案例能夠能夠成功救出來資料95%最大原因.
是因為客戶沒有先找其他廠商 .
其他廠商很有可能會先做了 rebuild 跟 fsck 都會造成很高的 資料恢復難度.
而是選擇了OSSLab實驗室 .
直接有效在短時時間搶救恢復客戶所要數據.
