on-host vs off-host backup proxy

[Perry]

I have two Hyper-V hosts servers A & B each running several VMs. The VMs are on the local drives of their respective hosts. Then I have a third server C where the Veeam backup app resides, performing VB backups to a NAS on the network.

I read the docs on this topic but its not clear to me why I would want off-host backup proxy. From what I've read off-host puts less load on the host but it's not clear how. If I had another backup proxy server D then data would have to be moved from A & B to D and then to the NAS rather than directly from A & B to the NAS. So why would I need an off-host proxy?

[Shestakov]

Hello Perry.
The off-host backup proxy must have access to the shared storage where VMs to be backed up and replicated are hosted, so the data has pretty same path, however since the proxy role is on the off-host server, the production host performance doesn`t have the additional load.
Thanks!

[Perry]

The VM data has to read from the host's drives anyway. Whether it goes to another server (the proxy) and then the NAS or directly to the NAS (no proxy), it still has to be read from the host so I don't see how the proxy helps other than adding more LAN traffic since now the data has to be moved twice.

1. Can you please explain in more detail how the proxy would help? How does it off load work off the host? What work is it that its off loading?

2. With my server topology described above wouldn't on-host backup make more sense since my VM VHD files reside on the host itself not on an iSCSI storage device?

[Shestakov]

Perry, backup jobs data flow is always Source > Proxy > Network > Repository, despite the mode you use.
The off-host backup proxy functions as a “data mover” which retrieves VM data from the source datastore, processes it, apply deduplication and compression and transfers created backups to the destination.
Thanks!

[Perry]

Could you please answer question 2 in my previous post. I have no common datastore.

[Mike Resseler]

Perry,

It still can make sense to have an off-host proxy in your scenario. What will happen is that the shadow copy that is made on your host will be transported to the off-host proxy and there it will be "handled" so it becomes your backup. It still will save resources on your host. However, the data will obviously more over the network and the scenario with a hardware VSS provider is not applicable for you.

Makes sense?

Mike

[Perry]

So if I understand this correctly, if I have a VM that is 200GB in size, with off-host backup, the 200GB will be moved to the proxy machine. From there the proxy will deduplicate and compress the bits. Now probably at much smaller size (let's say 50GB) the data is moved from the proxy to my NAS. That is 250GB of network traffic.

With on-host backup, all the processing occurs at the host, so only 50GB of total data will be moved on the network from the host to the NAS. Now this seems like a good benefit if the processing on the host happens in the host itself not the VM guest.

With the on-host approach where does the processing (deduplicate, compress, etc.) occur? On the hyper-V host itself or on the guest OS? In other words will the logical CPUs and memory assigned to the VM, being backed up, be used or the CPU and memory left over to the host?

It seems to me that if the host resources and not the VM resources are used for the on-host backup approach then the users of the VM will see no performance degradation while the backup is occurring and will also benefit from less network traffic.

Unless I am missing something, my conclusion is that in my scenario, off-host backup offers less benefit than on-host as long as enough CPU and memory is left to the Hyper-V host to do the processing since those resources are segregated from the actual VMs. The only resource shared between the host and the VMs is local disk access. I don't know how much of a problem that is though. Is moving the data from the host to the proxy more or less taxing on disk access than doing the deduplication and compression?

[Shestakov]

Your understanding is correct.
In case of on-host proxy usage, the processing and deduplication is to happen on the VM with VBR proxy role. vCPU of this VM is to be fully loaded by the time of backup processing.
Production VMs in that host will not be directly affected by the proxy, however if the host has a lack of resources, the production VMs will be slowed down.

Do you have statistics of previous backup job runs? It`s interesting to check what was a bottleneck.
Thanks!

[Perry]

The bottleneck is "Target" on Full Backup and "Source" on incrementals.

[Shestakov]

That`s probably because of backup method.
Some methods require doing 3 I/Os while the VM snapshot is open. What method do you use?

[Perry]

I do full backups on Sunday and incrementals Monday through Saturday.

[Shestakov]

Got it. But is that reverse incremental?
Thanks!

[Perry]

No they are regular incrementals.

[Shestakov]

Usually bottleneck = Target either because of huge number of random reads and writes which happens on backup transforms or due to weak repository hardware.
Do you always have target as the bottleneck? Are synthetic/active fulls scheduled?
Thanks!

[Perry]

I don't do synthetics. I do weekly fulls and daily incrementals. All my bottlenecks are all "Source" now.

[Shestakov]

Good.
Did processing rate increase, are backups made faster?