先說他的備份環境大致是這樣:「所有 Production 的 Hyper-V Hosts 先將 VM Replica 到一台肚子超大的 Server 裡, 然後再用 Veeam 去備份這些副本 VM」
聽起來這個策略沒什麼問題, 在副本 Host 上備份根本理所當然, 不會去影響到 Production 的效能
但當備份到容量較大的 VM, 尤其是 SQL Server 的時候卻產生了問題
Full Backup 時總會遇到以下錯誤:
Processing Mercury Error: Failed to call wmi method 'DestroySnapshot'. Wmi error: '32775' Failed to delete VM snapshot, snapshot path '%2'.
Failed to create VM recovery checkpoint (mode: Crash consistent) Details: Failed to call wmi method 'CreateSnapshot'.
Wmi error: '32775' Failed to create VM recovery snapshot,VM ID 'ooooooooooooooooooo'.
Retrying snapshot creation attempt (Failed to create production checkpoint.)
Task has been rescheduled
Queued for processing at [Date Time]
Unable to allocate processing resources. Error: Failed to call wmi method 'CreateSnapshot'.
Wmi error: '32775' Failed to create VM recovery snapshot, VM ID 'ooooooooooooooooooo'.
在備份的 Repository 裡面的確有看到 vbk 檔案, 看起來很像有備份成功
但上述錯誤發生後該 VM 會卡在 Applying Changes, 後續複寫則全部失敗
且 Hyper-V Virtual Machine Management Service 無法 Stop, 重開機指令下去後要等待兩小時左右才能重開機成功
一步一步來, Workaround 的方式如下:
- 遇到問題後先將 Hyper-V Virtual Machine Management Service 改為手動啟動, 不要讓他開機自動啟動
- Stop Hyper-V Virtual Machine Management Service
- 下指令 taskkill /f /im vmms.exe 將 Process Kill 掉
- 重開機就不需要等兩小時
- 開好機後在 net start vmms 指令之後緊接著快速地連續下達以下指令
Get-VM "YourVMName" | Get-VMCheckpoint -SnapshotType Recovery | Remove-VMCheckpoint - 步驟 5 最好是多開幾個視窗, 連續下指令, 錯誤沒關係, 就怕來不及, VM 又進入了卡在 Apply Changes 的狀態
- 這樣做完後可以至少將 VM 的狀態復原, 後續再嘗試備份