Too many jobs at once

[GabesVirtualWorld]

Hi
Customer of mine has 10 jobs scheduled to all start 1min apart. The Backup Server does not have enough CPU's for all these jobs, but that is also not the point of his schedule. He thinks that by "running" them all at the same time, they will start as soon as the queue is free. This would be better then to first test how long jobs are running and then try to schedule them at those hours. I've never seen this before but I must say that when thinking it through, it might actually be a clever way of scheduling.

Are there any drawbacks of doing it in this way?

Regards

[tsightler]

This is the way Veeam is designed to work. You're not supposed to have to plan out a schedule manually, the entire point of the queuing system is so that it just takes care of it for you. I mean, think about a large customer with 1000's of VMs and lots of changes, they can't possibly plan for all of the possible changes that can happen. Now, I'll admit that starting them all that close might be a little tight, as each process does use some connections to vCenter and some memory even while it's just waiting, but you certainly don't have to get down into the minutiae of scheduling every job.

One thing to note is that the scheduler does have some inherent priority. If a job is started at 10:00PM, and another at 10:01PM, the first job has priority for resources. Now, that doesn't mean the second job won't start, because there are many factors involved, such as total number of snapshots per datastore, proxy task slots, repository task slots, etc., but in general, assuming the proper resources are available, Veeam will try to assign those resources to the first job before the second one.

[GabesVirtualWorld]

Thank you

[dellock6]

Usually it's a good choice to stack multiple backups in batches, like 15 or 30 minutes. In this way they are not queued too early and do not consume too many memory for the manager component to just hold them.