Off-host proxy in a VM

[nmdange]

I noticed in the documentation that using a VM as an off-host proxy is not recommended. I'm wondering what the reasoning behind that is? Performance? I have a VM that is a backup repository, and I'd like to use that same VM as an off-host proxy so the data transfer from the proxy to the repository does not use the network.

[Shestakov]

Hello,
The idea of off-host proxy is to shift backup processing from the source Microsoft Hyper-V host to a dedicated machine. If you assign the VM on the source host a proxy role, the processing load will still lay on the host.

[nmdange]

I guess I should clarify, the backup repository VM in question is running on a standalone physical server with local VHDX files for the backup repository, so it is not running on the Hyper-V clusters being backed up.

[Mike Resseler]

Nmdange,

For the role of off-host proxy you need the hyper-v role. Which means you would need to run nested virtualization. In the case of evaluation you certainly can do that. But in production I am not so convinced because of the performance loss.

[Shestakov]

Technically you can enable hyper-v role on VM, but it will slow down the performance.
Here is a user guide section clarifying Off-Host Backup.

[nmdange]

Yes I read that section of the guide, hence my question

Right now my setup is like this:
SOFS SMB Share -> Network -> Physical Off-host Proxy -> Network -> VM backup repository

So I'm thinking this would be better:
SOFS SMB Share -> Network -> VM running both off-host proxy and backup repository

[PTide]

So I'm thinking this would be better:
SOFS SMB Share -> Network -> VM running both off-host proxy and backup repository

I think that would be better if it was the network between the proxy and the storage slowing down the job. Do you have bottleneck stats at hand by any chance?

Also, why not to assign the roles of proxy and repository to the same physical machine instead?

Thanks!

[nmdange]

Bottleneck stat is source, so I suppose it might not matter so much, but still seems more logical to me to keep the infrastructure simpler.

I have the repository in a VM mainly because I'm using REFS and you can't move fast cloned backup files from one volume to another, so by keeping it in a VM I can do a shared-nothing migration to move the backups to a different physical server without rehydrating all the data. The other reason is to keep the volumes on the physical host under 64TB for Deduplication while the REFS volume for the backup repository inside the VM can be larger by spanning multiple physical volumes. I based it on this guide for DPM, but the concept is similar with Veeam since both are using REFS Fast Clone https://charbelnemnom.com/2016/10/how-t ... p-storage/