Best way to structure backup jobs?

[nmace]

I'm just wondering how people who have been using Veeam for awhile structure their backup jobs. Do you go with one large job for all of your VMs? I read somewhere that you shouldn't backup multiple VMs from the same time that are on the same datastore. So maybe I should build out my backup jobs to mirror my datastores (Backup Job 1 only backups up VMs on Datastore 1, etc).

I'm just curious how people have went about it for their environment. Thanks.

[foggy]

Best practice is to group similar VMs (such as VMs with the same OS or VMs made from the same template) in the same job to achieve better deduplication ratio. We always recommend to have fewer jobs with more VMs in each, rather than more jobs with fewer VMs in each. Please find more details in the following topics:

Backing up and Restoring to/from tape
change request list for DR
The utter tedium of adding individual backup jobs

[nmace]

I'll check out those links, thanks.

Does Dedupe happen just within each backup job? Or does Veeams ability to dedupe span across multiple jobs?

[Vitaliy S.]

Deduplication is per job only, if you want to achieve deduplication across all jobs, then you should be looking at dedupe appliances.

[soylent]

I have about 50 VMs, and I want to know if there are advantages or disadvantages to creating a single backup job with all 50 VMs?
Are there any performance or deduplication issues, or problems with managing the job?

[foggy]

Max, please review the considerations given above and don't hesitate to ask any further questions, should they come up. Thanks.

[dellock6]

A quick answer is yes. In the past, single job would be good for deduplication but hard to optimize in terms of performances since each VM would have been processed sequentially. With V7 and parallel processing, even a single backup job can be executed as fast as possible, given a certain amount of proxy processing slots.

Luca.

[BackupDude]

Greetings,

I am trying to understand if there is a benefit to creating a job for each VM or a single job with all the VMs. In a mid-size environment, it wouldn't be a question to use a small number of large jobs, but I've taken over management of a Veeam solution for a customer, and they have a job for each VM (5 total). They dont use any type of dedicated repository with HW data deduplication. Backup data is stored on the Veeam server using standard compression and dedup.

Thinking out loud here but my guess is that since each backup which contains a single VM is stored on the Veeam server, deduplication wouldnt be nearly as effective compared to having multiple VMs in a single job. Since Veeam is only backing up one server at a time and storing data in its corresponding folder, the data deduplication ratio would be lack luster since its not aware of data in the other jobs/folders.

On the right track with my thoughts? Any advice would be appreciated. Thanks

[veremin]

Yep, you're completely right here - there is no deduplication among multiple backup jobs. More considerations regarding job structuring can be found above.

Thanks.

[gingerdazza]

Hi. We are building a new Veeam solution. We have VMware 5.x clusters, 1Gbps NIC, HP EVA SAN over 4GB FC. B&R server is physical DL380 Gen9 LFF with local SATA disks. I'd like some advice on job setup...

1. Is it recommended to backup as many VMs in a single job as possible? Or split them up?
2. Is it best to have separate jobs per OS for dedupe? Or is it fine to mix OS VMs?
3. Does putting too many VMs in a job affect the restore time (i.e. searching through file for blocks relevant to restore)?

Thanks

[foggy]

You can find some considerations regarding your questions above and in the topics mentioned in previous posts. Besides dedupe factor, there are also other ones to keep in mind, like grouping critical VMs that have lower RPO or VMs that should have similar retention.

Backup file size can affect restore time in some restore scenarios (FLR, restore from tape).

[PTide]

Hi,

1. Is it recommended to backup as many VMs in a single job as possible? Or split them up?

Also, if you ever decide to use storage snapshots then it will be more convenient to group VMs in jobs by their location on storage LUNs so all VMs can be captured by single snapshot. On the other hand - the more VM's are placed in single job the more resources you need to process them.

Also this thread is worth checking.

Thank you.

[jcapone]

I have one comment on this and hoping for some input: while I do agree it's best to have fewer jobs with multiple VMs in each, I have run across one problem, particularly for SQL servers - when the job fails for whatever reason, or if a transaction backup job fails, you may need to kick off an Active Full backup to allow the transaction log backup chain to start over. I know you need to do it for all SQL servers in the job, but if some are more critical than others, you may want to prioritize their Active Full, and some you may even put off until the next weekly full runs. But if they are all in the same job, you can't do that. You can re-order the VM's in the job, but you are forced to run an Active Full on every VM in the job, which may not be what you want. Anyone have any advice on this besides re-ordering the VMs in the job?

[nwbc]

I do not know about a possibility to pick certain VMs of a Backup Job and just processing them. However, the retry button on failed backups will only try the non finished backups. So if one VM in the Job fails, and you just want to Backup that one machine again, you can do with retry - though you can not configure what kind of backup it will do.


Atleast, this is the behaviour I know about.

[jcapone]

OK thanks, that's good to know.