Veeam Replication Performance & Best Practices

[guillermo.lozano]

Hi Community,

After troubleshooting with Veeam Support over the case [ ref:_00D30RWR._50060P9GCg:ref ] we've found the problem:

Since my infrastructure is small I have installed VB&R, Source & Backup Proxy, Veeam One & Enterprise Manager on the same VM and this VM is part of one of the concurrent replication jobs.

When this job processes that VM, all other concurrent replication processes display the message "Waiting for backup infrastructure resources availability"
In the log files this is the message that matches the description: Proxy is backed up/replicated now and cannot be used.

My workaround will be replicating /backing up this VM separately at different times o install another proxy server as source which won't be replicated.

I Hope this helps.
Thanks again.

Best Regards,
Guillermo.-

[DavidReimers]

I am looking at doing something similar. Essentially what I want to do is to (a) backup about 12 critical VMs to a Windows repository with the Veeam proxy installed; and (b) replicate those same 12 VMs to an ESX Server at a remote site. As these jobs are set to run sequentially, failure (actually, a stall, such as the snapshot not releasing) of the first job means the second job won't run.

Can I run these two jobs simultaneously? Even though they will both be essentially trying to access the same source VMs?
Or should I split the backup / replication jobs into 2 jobs of 6 VMs each, and run those 2 sequentially, then run the second pair of jobs after that?

[veremin]

Hi, David. Please be aware that it isn't possible to access simultaneously same VMs by two different backup/replication jobs. The job splitting might do the trick.

Thanks.

[foggy]

Consider starting your jobs using PowerShell, this will allow you to chain jobs with no dependency on previous job success/failure. Or specify different VM processing order in two jobs and start them simultaneously.

[DavidReimers]

Hi, David. Please be aware that it isn't possible to access simultaneously same VMs by two different backup/replication jobs. The job splitting might do the trick.

Thanks.

I figured as much. Is there an easy way to split the jobs in two? I'd rather not lose the existing VM replicas. If I remove VMs from job A and add to Job B, will it automatically find the replicas and their restore points?

[veremin]

You will have to create two different replication jobs and map them to already existing replica VMs. However, be aware that in this case previous restore points will be merged, and after the initial replication run, there will be only two available.

Thanks.

[guillermo.lozano]

Hi,

In my setup, I ended up using two VB&R servers (one that handles backups and the other is on the DR site managing replications) with four different proxies (2 for source and 2 for destination).

I chain one job after the other using PowerShell remote.

Regards,
Guillermo.-

[DavidReimers]

You will have to create two different replication jobs and map them to already existing replica VMs. However, be aware that in this case previous restore points will be merged, and after the initial replication run, there will be only two available.

Thanks.

I've done this, replica mapping appears to have worked OK. Is this something I can then turn off i.e. to get the restore points building up again, or am I missing the point?

[veremin]

Mapping is one-time process, after initial synchronization everything will work as it used to - each run of replication job will create a new restore point.

Thanks.

[foggy]

And you can safely disable the "Low connection bandwidth (enable replica seeding)" check box once you have run at least one successful incremental job pass. No need to keep it enabled after you've initially mapped the job to the existing replica.

[DavidReimers]

Thanks for the quick reply guys!

[DavidReimers]

And you can safely disable the "Low connection bandwidth (enable replica seeding)" check box once you have run at least one successful incremental job pass. No need to keep it enabled after you've initially mapped the job to the existing replica.

That's good to know. I left it on for a run last night, and each of the jobs which had _previously_ run with replica mapping ON took longer, and the delay was all around 'calculating digests' for the disks.

[foggy]

Did they take longer than the previous job runs with the check box on? Looks like something wrong has happened to the digests then. Digests calculation is only required in cases where the replica VM state is not consistent with the currently stored metadata. I mean it is not dependent on this check box on subsequent runs (unless you've changed something else in the job).