Recommended max number of VMs in a per-VM backup job?

[ShawnKPERS]

There have always been recommendations to break up jobs with a large number of VMs to optimize for sizing issues of repositories and other storage/job related considerations. But with per-VM backup I always wondered if that is still the case as each job looks to already be setup as granular individual jobs themselves. So is there really a limit to how many VMs are recommended in a single job if you use it in conjunction with the scale-out backup repository feature?

I just saw a reply by dellock6 on this recent post veeam-backup-replication-f2/too-many-jo ... 37592.html talk about consuming more than a required amount of memory just to store VMs sitting in queue to be backed up. Is this true is there an additional memory hit for just holding a VM in queue to be backed up and if so I assume it the memory it is on the backup server itself and not on the proxies? Also is it a substantial amount?

That is the only possible thing I can see that may discourage the idea of not breaking up a tone of VMs into separate jobs.

[tsightler]

Actually, it's having the jobs queue up that consume the memory, not the VMs. Every job in Veeam has a separate manager process (Veeam.Backup.Manager.exe). For jobs that run in continuous mode, like backup copy jobs or some tape jobs, you will see this manager process in the task list all the time. For regular jobs that run on a schedule, when the scheduled time start, a new manager process is started, this process communicates with vCenter, creates the list of VMs and the resources they are own, and begins looking for available proxy/repository resources to assign tasks. If I have 10 jobs start at the same time, there will be 10 new manager processes that pop up and they will live until each job is complete. Obviously each of these individual processes use some memory, typically a few hundred MB each, but for large environments it can be more.

With per-VM, nothing is different really, except, as a general rule, it is possible to put many more VMs in the same job since you don't have to be as concerned about the backup file size, but there are still practical concerns to take into account. For example, what if you do need to run a full backup? If you have 250 VMs in a job, you have to run it for all of them, there's no way to run a full for only a single VM. Also, processes like synthetic operations, backup copy jobs, or copies to tape only start after the entire job is complete, which might take significant time. If you have mulitple jobs, some of those secondary operations can start prior while other backup jobs are still running.

Today, as a general rule, I recommend a guideline of ~100 VMs in a job that is configured with per-VM. Certainly it's possible to do more, and if you have many very huge VMs, it might still be valuable to be much less than this, but I think this is a reasonable number to start with. I expect this number to be considerably higher with 9.5 and the continuing enhancements we've made there on the scalability front, some of which are mentioned in this great blog post from Rick:

https://www.veeam.com/blog/enterprise-s ... suite.html

[ShawnKPERS]

@tsightler, thanks for the clarification and link to the post. I had one job planned for it that also follows up with a continuous mode tape job that may cause some issues so looks like at least for that job I will still need to break it up.