Told by support not to group more than 5-10vms ?!

[Yuki]

What we have:
- case: 000635889
- 3 Dell vsphere hosts, local storage only.
- 14 VMs
- single on-site backup job with all VMs in it going to on-site NAS
- single off-site copy job with all VMs in it going to off-site proxy with NAS behind it

We were having random errors and issues with the local and remote job, some of them were an oversight on our part done by a person still learning the ropes (putting Veeam on pretty busy VM doing other auxiliary tasks, not monitoring this system and having another processes fill all available space, etc). Some of those have been fixed and we are preparing for a re-do of the proxies, veeam server, new seed and off-site copy job.

However, we've been told by Veeam support engineer

1. Reduce job overhead by splitting up the source backup job into multiple jobs. (5-10VMs per job)....If possible, I would separate VMs that require VSS (SQL, DC, Exchange, Sharepoint) from other servers that don't. (File servers, terminal servers, etc.). Use the "Advanced" section under "Guest Processing" to selectively process AAIP only on the VMs that actually require VSS to save even more time during backups.

- it seems that multiple jobs will only increase overhead since dedupe ratio is likely to be lower with multiple jobs and more of same data transferred. Also why disable VSS for file servers and terminal servers? I thought file handle locks are also processed with VSS (I may be mistaken here).

2. Specify your backup proxies. Currently Proxy selection is handled automatically, and it tends to choose your Veeam server as the proxy each time. Whichever backup job does process your "Utility" VM, make sure it is setup to be processed by a different backup proxy, other than itself.

- Veeam stated multiple times that automatix selection methods are very efficient and "smart" and automatic mode is often preferred (without giving out too much detail on how it makes those decisions). Having said that, i know that in some cases manual selection is best. The problem is - if we group VMs into multiple jobs and do it based on the role/function basis, then we will end up with 1VM on one host, 2 VMs on another and 2 on a third. And Veeam does not allow granular per VM proxy assignment, instead it is per-job. So we would have to add all the same proxies to every job anyway, as otherwise they wont be able to use hot-add mode.

So whats the definitive answer here?

[Gostev]

Hi, Yuki.

I have asked our support management to check on this support case, because obviously both of the quoted statements above are completely incorrect from my perspective.

1. There is no limit of VMs per job aside of backup repository capacity and its file system capabilities. There is no good reason to disable VSS for any Windows server whatsoever. And, there is zero sense in separating applications requiring VSS, from those which do not, into a different job.

2. Intelligent load-balancing does not "tend" to pick any specific proxy server. Instead, it will pick proxy server least occupied with tasks (at that very moment) that is capable of backing up a majority of VM disk in the "best" processing mode (with an order of preference being Direct SAN > Hot Add > Network).

Thanks!

[Ben Milligan]

Hi Yuki,

Ben Milligan with Veeam Support. I apologize for this confusion and I'm working with the engineer you were working with to correct the mistakes made in the suggestions for your issue.

There really is no reason you cannot group more VM's per job, so I'm unsure here why my engineer suggested this. You are correct that deduplication will not be as efficient with multiple jobs.

Automatic selection of the proxies should be perfectly fine to use as well, since it will do the work for you in finding which proxy will be the fastest. If that is the VMware Backup Proxy (Veeam console), that's ok, it has just been confirmed as the best option for that particular VM being processed.

[Yuki]

Thank you, I appreciate you taking a look into it.

We are also correcting all configuration issues on our side (deploying new proxies and moving Veeam to a separate VM).