Best practice backing up virtual machines

Can you run 100 VM’s in a job, yes you can but you need to make sure the proxy and repository have enough resources to run that many VM’s in your RTO/RPO

I would create smaller jobs based on backup interval. I create Tier I, Tier II, and Tier III. But anything that you need to backup more frequently in Tier I, anything that needs to run every 4 hours in Tier II. Then what needs to run daily in Tier III. 
 

I'd recommend to always have as few jobs as possible only. This keeps management efforts low when you have to make changes to the jobs. Also keeps it the interface nice and clean. 

The speed of your backups will still always be maximized as veeam is driven by its scheduler that makes no difference between your number of jobs as it operates on a task level with each task being a VM and it's virtual disks underneath.

Hi ​@MEubanks -

Welcome to the Community! There really isn’t a “best practices” per se’ when it comes to Jobs and VM count. There are a lot of “it depends” things when deciding what’s best to do for backing up your VM workloads. Do you have physical resources to use for Proxies to have better backup speeds? If not, do you have VMware resources to create several Veeam “hotadd” Proxies to handle your backups? Do you have snapshot “stun” limitations for any of your VM workloads? What are the retention SLAs for your VM backup workloads? Etc., etc.

All that said, as already shared, it’s best not to have a single Job for your VMs. Could you do so? Yes, if your Proxy (only a physical box could handle this) had the needed resources to do so. But, it’s best to beak your Backups up into separate Jobs. If you have dedup backend storage, it’s generally best to have similar OS VMs in the same Job to take advantage of this kind of Repo storage (but not necessary). Do you have infrequent change VM workloads (small Linux VMs, front-end Web Server VMs, etc)? You could put all of those in a Job and run them daily. Those are just a couple of examples of things to think of. For more info on how to look at and/or configure your Jobs, you can see this section of the Veeam Best Practice Guide:

https://bp.veeam.com/vbr/4_Operations/O_Veeam_Jobs/O_backup_jobs/

Let us know if we can help further.

Best.

You would definitely want to split into multiple jobs. In addition to Tiers as mentioned, you could also organize/group VM’s based on their workload. 

Hi ​@MEubanks,

best practice is to use vSphere tag and tag them - based on retention period

100VMs is not a problem to backup, everything depends of amount of proxy servers, repository - how many concurrent tasks you have - we have 64 tasks and few jobs have around 500VMs each

issue becomes, if 90 VMs have 300-600GB and 10 VMs they have 50TB each :)

then i would split big ones into another job to avoid issues with synthetic or active full backup, which will be longer or check of block corruption - which will block daily scheduling of backup for other small VMs ...

correct me if i’m wrong.

Old way was separated by OS (Windows/Linux).
Today i still essentially do this, but i separate based on “service provided”(dept.) and again based on “storage size”

examples:
a bunch of windows “workstations” → 1 job
a bunch of small windows servers → 1 job
a bunch of small linux servers → 1 job
syslogging servers → 1 job
ERP linux → 1 job
ERP windows → 1 job
ERP database → 1 job
video [recording/media] servers → 1 job (or possibly 1 job each if multi-terabyte)
security specific servers → 1 job

so here minimum 9 jobs for this example.

Hi ​@nd39475_c - yeah...you’re not wrong there. Way back in the day, yes...it was recommended (not a best practice), to put like OS’es in the same Job if possible, especially those VMs created with the same Template, to make dedup work better. Yes...I agree...it’s generally best to have similar workload “type” VMs in the same Job (i.e. Databases, etc), or at the very least similar “Tier” levels for workloads which require the same Retention SLA.