Odd vm restore behavior [NBD]

[jcofin13]

Do the veeam proxies need to be on esxi hosts that can talk to the destination storage when doing a full vm restore?

I just moved our veeam server and 3 proxies to a new cluster of esxi hosts as i am working on a hardware refresh. I was doing a test restore of a VM. The first vmdk in the vm restored using a local proxy (one of the ones that was moved) but it used [NBD] mode rather than Hot Add.

The second vmdk on the vm being restored used a remote proxy in a remote office and also used [NBD] rather than hot add. This remote proxy is not even part of the original backup job in which the original vm was backed up. Im not sure the logic veeam used to select this proxy over the other 3 local ones.

I canceled the restore as it was really really slow due to the remote proxy, then moved the veeam server and proxies back to the original vmware cluster and it seemed to work as expected. Hot add and local proxies were used as expected.

Not sure what is going on other than the new cluster cannot see the destination storage lun where i was trying to restore to. Of course neither can the remote office proxy that it chose to use the second vmdk file so i am very confused.

[david.domask]

Hi jcofin13,

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

I'm guessing you are correct on why hotadd is not possible here, but it could be because of a few reasons -- check the requirements and limitations, the main ones I think that may apply would be:

- The VMware backup proxy and processed VMs must reside in the same datacenter.
- The VMware backup proxy must have access to disks of the VM that this proxy processes. For example, in a replication job, the source VMware backup proxy must have access to the disks of the source VM, the target proxy — to the disks of the replica. If a VMware backup proxy acts as both source and target proxy, it must have access to the disks of the source VM and replica. In restore operations, the VMware backup proxy must have access to disks of the restored VMs.

In short, that it worked when you moved the proxies back makes me think it's one of those two.

Is it feasible to add a few proxies on both VMware environments? A vanilla Ubuntu or Debian proxy should work "out of box" and shouldn't take too long to deploy or be too resource intensive.

If you still cannot get it going, it's best to let Veeam Support review the issue in a case to check the logs and see why hotadd wasn't feasible, but I'm pretty sure it's as you are supposing. If you open a case, remember to include logs; use the 3rd radio option when exporting logs and select the Veeam server itself to export from, and be sure to mention the name of a VM that can be used as a reference for review.

[jcofin13]

Thanks
I figured out that it appears to be down needing proxies in each cluster after some testing. ITs hard to explain without a diagram but i can say that if want to restore to storage that only 1 of the 2 clusters knows about then that destination cluster with that storage has to have a proxy or it will run in NDB mode based on my testing.

In this scenario i am restoring a vm to some older storage that only 1 of the 2 clusters has access to. Once that cluster had a proxy in it, veeam would select that as the proxy for the restore and use Hot Add as expected.

[david.domask]

Glad you were able to figure it out, and your findings are correct as per my understanding; without the cluster (datacenter) "knowing" about the storage, hotadd won't work, even if the proxy technically can attach disks from the same storage -- it must be in same cluster (datacenter) that also knows about the storage.