Replication job - long delay on "Using target proxy"

[james411]

I'm trying to setup a replication job with 2 VMs to run as often as possible (was trying for at least every 15 minutes) and I'm noticing the longest delay in the job is on "Using target proxy <proxy name> for hard disk [hotadd]"

Since the job details don't actually show a time for this step, I've timed it and it takes slightly over 5 minutes to move from this step and actually start processing the VM's disk (see image below). Is this normal? Is there a way to speed this up?

Relevant information (I hope):
2 ESXi 5.5U2 hosts (both have local storage)
There is a VM installed on each host with Veeam proxy components (both are Windows 2012 R2)
Source proxy has 2 vCPUs and 6 GB of RAM
Target proxy has 2 vCPUs and 4GB of RAM
Parallel processing enabled, proxies limited to 2 tasks
Running Veeam 8.0.0.2030

Thoughts? Thanks!

[alanbolte]

Try updating Veeam to Update 3; I've seen a few delays resolved, though that was either database-related or on a more recent version of ESXi.

Try forcing the target-side proxy to network mode: it might have a slower write rate, but if you're not writing much data anyway that won't matter. Hotadd has some unavoidable delays due to the mount/unmount process.

[james411]

Tried Update 3, didn't seem to make a difference.

Switched the target proxy from Auto Selection to NBD mode and made a huge difference. It completes the "Using target proxy" step almost immediately now and allows my job to complete in about 8-9 minutes. 2 questions though:

1) It seems the longest step now is the "1 restore point removed by retention policy". This can take from as short as 30 seconds to as long as 4 minutes. Is there anyway to speed this up?

2) Is there a way to have the proxy use hotadd for the backups of VM that are on that host, but use NBD for this replication job only?

Thanks!

[alanbolte]

1) Check if restore point removal speed is dependent on VMware snapshot removal time on the replica VM.

2) Not directly. There are a number of ways to trick the mode detection into using NBD or force a failover; the problem being that some of them will introduce more delays, and others will be impractical for your particular situation. Probably your best option is to have two separate proxies. While I don't generally recommend putting any Veeam role on production VMs (opinions differ on this...), there's very little that can actually go wrong with network mode, so if you don't want to build a dedicated server, you could perhaps choose one of your less critical existing VMs.