folder list of VMs? Best way to consolidate

[technerd]

Looking to see if anyone can offer some advice.
We have 2 servers currently, each backing up a cluster.
Both clusters are visible in the same vSphere server. One is for ERP systems (and a few others), the other is for "other" servers (file servers, IIS, SQL, etc...)

I'm looking at re-working some storage soon. Instead of 2 servers, I'm leaning towards putting everything on one. One reason is that on the "newer" one (which currently handles ERP systems), it's running 2012, and we get "so-so" dedup out of the built in OS deduplication. Another reason is that it'd be nice to have things consolidated.
One issue I don't look forward to is a giant, "galactic list" of systems (nearly 100), and the management of it within the veeam console is a little less than what I'd consider optimal. Selecting a job, for example, brings up the lower pane, and that's always a mess. It's slow, and it immediately cuts your view in half when you don't always need to see that.

In any case, I'm wondering if there's any good way to break jobs lists up into folders. Don't think there is, but I thought I'd ask, and see how others handle "larger" number of servers (I realize there are others with MANY more VMs). Do you have several, smaller Veeam systems, or do you break up jobs in larger groups?

[dellock6]

Hi Antonio,
we have indeed customers with thousands of VMs, running also multiple Veeam servers, not just multiple jobs. But for jobs themselves, I've seen anything from 1 VM per job to 50-60 VMs in each. Personally I like to keep backup files to 4-5 TB of max size, mainly for management reasons (like having to move it around sometimes), but the number of VMs that can go in it depends on their size and change rate, and also how they are similar (put all windows VMs in a job and the portion of the operating system is heavily dedupe since it's the same for all the VMs...)

I don't get the painpoint in opening the VM list of a job, for daily check you just need the report telling you for example 20 of 20 VM completed successfully... For restore operations, you go and seach for a needed VM directly into the "Backups" node of the main backup & replication tab, as soon as you write the name or a part of it, the VM shows up with the job where is stored, and from here you can start immediately the restore.

[alanbolte]

If you'd prefer to disable the lower statistics pane, you can do so in the View tab of the ribbon.

[technerd]

Thanks for the replies!
I will check on the view setting. The pain point there is when having to go into the console, it's just slow to render when selecting a job to view/edit.

As for consolidation of jobs, I have several that are grouped, though I'll be re-working this when the storage is ready.
I've had issues with Veeam on server '08 with a couple of jobs where one VM within a job fails to start on occasion, though I'm not opposed to trying again. The other issue is running jobs "after" the previous one. I've been told by support that this can cause issues which I've had - notably, that the retention doesn't seem to keep up, and I'll end up with, say 30+ copies of a job that I should only have around half that. I'll schedule them manually I suppose.

My thought for "folders" is just that I would prefer to at least group the jobs by virtual cluster. It's not feasible with our environment to just put all VMs from each into a small set of jobs. Sure, there are some similar systems where the dedup helps, but not all. Either way, it would be nice to see one more level under "Jobs\Backup" such as "Jobs\Backup\Folder(Cluster)1, Folder2" as an example, or within the main window. Not a big deal, I'll sort it out. Thanks again!

[foggy]

The other issue is running jobs "after" the previous one. I've been told by support that this can cause issues which I've had - notably, that the retention doesn't seem to keep up, and I'll end up with, say 30+ copies of a job that I should only have around half that. I'll schedule them manually I suppose.

Yep, jobs chaining can easily result in issues like that, that's why we do not recommend doing this.

[technerd]

Nice. Thank you.
One question on this statement: "...you'd better limit tasks concurrency on the proxy (or the repository) and let all the jobs start together..."

Say I start 50 jobs at 5PM, with limit of 4 concurrency. Will any of them "time out" and not run, if they go into, say 1AM 'start' time on the last few?
The only part I'm not clear on is the 'window' within which the "scheduler" deems it appropriate to automatically allow the next job to run, and/or the "retries" setting within job properties.

I believe the reason that people go with chaining, aside from it seeming "logical" to them, is that it's not clear on the points above
1) when is the "timeout"
1a)-within 24hrs?
1b)-After midnight?
1c)-After 3 retries?
...if the answer is "none" then that should be more obvious - that the scheduler will simply keep firing away on it.
The only issue at that point would happen if your window is past a full day for incrementals, I would suppose. At that point, one would have "bigger problems" than the scope of my questions

If "the answer" lies with allowing the scheduler to work its magic, and that being the preferred method, I am FAR more clear on this now, after reading through those threads, and thank you for linking to them. Still a tiny bit unclear on a couple items, but, overall, understanding it MUCH more clearly as to the "why" and "how" of this.

[foggy]

I believe the timeout is 23 hours, which is logical since, as you have correctly pointed out, you would not want your daily jobs to rush into the next backup window (better add more proxies or allow more concurrent tasks on existing ones).