Some time ago I had one of those rare days where I struggled to restore a VM using Veeam Backup & Replication. Some would claim that this has nothing to do with Veeam Backup & Replication, but is solely due to the choice of hypervisor. At this point, I would neither agree nor disagree with this claim, but there is definitely a reason why VMware is ahead in the field of server virtualization.
Actually, the whole thing should have been a fairly simple undertaking: Restore a complete VM to a specific point in time. At first everything looked fine, but after the virtual disks were restored and the VM should have started, the fun began.
For some reason, the restore didn’t want to work for the heck of it. The customer had already tried to restore the VM to the original location. He was not sure if the original VM still existed or not. So I didn’t really think about it and decided to delete all leftovers of the original VM and tried to restore it again. But this attempt was also unsuccessful and failed with the same error. I used the time it took Veeam Backup & Replication to restore the virtual hard disk for a short online research. To my surprise, I did not really find anything.
I decided to make one last attempt before opening a support call for the issue with Veeam. Instead of restoring the VM to the original location including the network configuration, I decided to restore the VM without the network configuration. Of course, the restore options of Veeam Backup & Replication offer a possibility for this as well.
Besides the location, the virtualization host, the datastore, the name of the VM and the network mapping can be changed in this dialog.
Without a connected network, the restore of the complete VM went through without further issues. Additional adjustments were not necessary.
After successful recovery, I was able to connect the correct virtual network without further problems and start the VM. After a few minutes, the restored VM was available as desired.
I am certainly not an advocate of Microsoft Hyper-V and therefore spare myself any cynical comments at this point. Nevertheless, I can’t really understand the cause. Nothing has been changed on the VM, nothing has been changed on the virtual network, and yet the recovery only works in a two-step process when the virtual system’s network connection is not connected during the actual recovery. Probably not a bug but a Hyper-V feature (and now I couldn’t resist the cynical comment after all). In the end, the customer was helped and that is the most important thing.