Veeam backup - Daily backups - best practice?

[maxrebo]

What's the best practice for setting up backups in Veeam?, in my previous job I set up each Daily backup individually (one VM per backup job) in my new school they have one backup job for all the servers. Just wondering what the best way of doing it is, and how others do it?

 

Thanks

[localzuk]

There's no practical reason to do one per VM.

 

The only reason to split the daily's IMO, is if you have different backup requirements for the actual VM - where it backs up to, any scripts to run etc...

 

When we ran Veeam, it was just one big daily job.

[Davit2005]

At the last place we used to do each datastore on the SAN, if a VM was on a datastore it would be backed up by the job. Then I changed it to groups of servers that are doing similar roles or don't need Application awareness or other different backup requirements. We did have 16 hosts at the time with increasing amount of VMs, increasing the 40 that were there in the early stages of virtualization and/or migrating the services to new servers Edited February 8, 2023 by Davit2005

[psydii]

Our Veeam solution was designed by someone who went off to be a Solution Architect at Veeam. For the huge (too big in her opinion, but customer demanded) VMs there was one job per VM. Then there was one job for the rest of the datacenter.

 

Over time we've broken it down into more jobs, primarily to make it easier to see when a VM has failed its backup rather than it marking the whole job as failed we see individual notifications for each server. Also when moving to backblaze it was easier to lift individual jobs to the cloud rather than the entire datacenter. There is more opportunity here for mistakes though - have we got the right exclusions, have we really backed everything up? With a Datacenter level job you know you've got everything.

 

Generally though I would recommend following the best practice / example guidance from the Veeam site - 3rd party engineers really love it when then encounter systems that were clearly configured following a standard design pattern.

[jthompson]

One job per VM here. It allows us to individually tweak the storage options like GFS or number of retained restore points. It also means that a job can be retried or run on demand without running backups for other servers unnecessarily.

 

Something else that comes to mind is licensing. When a VM gets takes out of service, it's stored backups will still consume a Veeam license. If it's backups are isolated in an individual job, then it makes it easier to purge those backups from Veeam and free up the license. You might still be able to free up that license anyway, but I guess the backups are still easier to get rid of.

[penfold]

From memory when I was using Veeam we used a combination of both. If I remember the reason for 1 backup was to allow Veeam to use deduplication to save space on all the severs which have the same build. However, we configured type of systems so we could group the same type of servers together. This allowed us to take advantage of the dedup feature, but also have more granular settings for specific servers. Plus as others have suggested we also had different backup schedules for different servers. But this was also offset by the fact we also had replication jobs running for quick failover

[KK20]

1 per VM here. Different VMs get different backup destinations, retentions etc we also have different diskcopy for certain backup jobs but not for others. Edited February 8, 2023 by KK20

[DavR]

We've running 1 job for all VMs here, but, we've only got half a dozen VMs on one host being backed up, so it's no biggie.

 

In our previous, more complicated, server solution, we had one job running daily for all front line VMs and data, and one job that only ran on a Sunday to backup archive data. This was to allow us to save storage on the backup repository, as we only needed one copy of the archive data, not a two week history and multiple copies.

[Guest Guest]

We run two daily backup jobs, the first for SIMS and file servers, the second for DCs etc

 

Its set like this as we only retain backups of DCs, SCCM etc for 30 days and 180 for the others

[Steve21]

1 per VM here too, many benefits of that method for only a slight loss of dedup/compression.

 

Can schedule different times/restore points/frequency etc. Allows easier migration/off-siting if smaller too. Less likely to corrupt a whole chain. Can run a full on a single VM easier if required (e.g. before an inplace upgrade)

 

Steve

[PotNoodleTech]

I've got 2 different backup jobs

 

One for our main 3 Vms with all pupil staff and admin data on, and one for the rest of the servers. It makes it easier to set different copy intervals or differnt backup copy jobs - i.e I want those 3 main servers backed up day in day and coppied to the cloud wheras the other servers really don't matter quite so much and thus the copy jobs dont run as often.

 

Seems a bit of a waste of time having seperate jobs for every server?

Edited February 13, 2023 by PotNoodleTech

[slugshead]

Last place I worked I did around 50vms in one job start at 7pm, then a backup copy job once that's finished.

 

Current place I work and the setup I've inherited, the VMs are grouped and the start times are staggered. PITA to be honest, i get about 10 email notifications per day about various backups.

[mdrabble]

I have mine in 3 groups, critical, non-critical and Linux Based with staggered times and different retention policies.

[CHiLL]

We have 1 VM per job, with all of them scheduled to go at 10pm - but limited to 4 concurrent jobs at a time. We used to have them grouped and the reason we moved away from that is because we'd often get a job stuck in the group, which would delay the entire group. It also gives us the benefit of if we ever need to recover from a disaster and download the backups from the cloud - we can download each server individually and get the recovery process started earlier with the most critical server first, rather than waiting for the entire group to download.

[Julian]

Our VM are in groups (based on the VMware groups), Veeam backup with 1 backup job per group, daily, reverse incremental, with second job set to start when the first job finishes.

 

As the Backup jobs are for groups of Virtual servers, when a new server is added, it automatically is included in the backup.