Job design..

[1dna]

Hi Again,

(Yet Another Job Design) Post .. hehe

Anyway - been reading others, so figured i will better be starting off.
We are slowing migrating variosu datacenters into 1, and closing down other sites - where a complete redo based on tags is coming abroad so basicly we are trying to boil down 200 jobs to under 20.
But i ran into a challenge to where where i was tasked to create an audit report from veeam one where i realised - im not sure few biggerr jobs is always a good idea?

We have:

1 HP Server with 60 disk (Repo/Proxy) - and Veeam enterprise plus. (this server has 2 CPU and 64gb MEM.
We have around 520 VMS in a mix of linux and windows ( 65 SQL servers ) and around 300 TB of storage and 2-2,5 TB daily changes.

in the early mornings - no more than 200 vms per job, but this proxy is performing outstanding with 300 currently - but it do not seem like an good idea if you want to test the backups, tags and split them and put some offsite and do others reporting from Veeam one.

Have anyone been doing the same with a few job with many vms ? and move to another design ? i would love to hear more.

[JGM2023]

In my opinion the only benefit to having more jobs Is for scheduling reasons, or If a subset of the machines need a long term backup for example.

Theoretically Veeam will work In the same way If you have multiple jobs or 1 Job. As long as task slots are configured correctly on Proxies and Repositories.

Veeam BP site says a maximum of around 300 VMs, So I would still stick to that number. https://bp.veeam.com/vbr/4_Operations/O ... ckup_jobs/

Testing backups Is exactly the same process, Job size does not affect this as far as I am aware.

[vmtech123]

It really depends on your environment. I've seen people with 1 job, and I've seen people use 1 VM per job.

My self, I have a few heavy populated jobs with many servers. but try to keep them organized. Some by a specific application (db servers, app, web, file etc.) and others by application type, (web, app, DB) and most of this is for reporting, retention, and organization.

There also ends up being a few jobs for short term and long term retention and other factors.

For me, i have many many file servers over 50TB, some over 100TB. They go in jobs by themselves. Same with the copy jobs. If i want to move delete, modify, resync, or use in application groups, I like it granular for those monsters. Same with some of the 20TB+ DB's. Those get treated alone. Tiny servers get grouped together.

When I run my jobs, I kick off a bunch of file server jobs at once still. When i run the applications/app server jobs with 50+ VM's, they are scheduled solo.

I treat jobs logically for the above reasons rather than "performance" related. Most is down to reporting and retention policies however. "How much is app X costing us?, How much space is app X taking up?, or we need to keep app X for 2 years!!!" Much easier than having 1 job for everything.