Often when looking at Best Practices guides, software documentation, or even during education, I see and hear the answer “It depends.” This is probably my least favorite answer, as someone who likes to understand why something is right or wrong.
While it does “depend,” it makes it very tough for people starting out to understand the “why” in many cases. One thing that is not going to be the same for every Veeam user is how the jobs are created.
Over the years, Veeam has made some fantastic changes and for most environments, Per-Machine backups are the way to go, the minimal savings you get do not compare to the performance and portability of this mode. Additionally, with this mode you can often add a HUGE amount of VM’s to a job and just forget about it. I know of people who have 1 job. That is the definition of an easy button!
Today I want to discuss some reasons that myself and others have gone the other direction to separate jobs. While I keep my jobs as large as I can for the performance benefits of concurrent work fully utilizing the available CPU resources, there are some situations where splitting jobs makes sense.
Different Schedules
While obvious, trying to schedule the jobs at different times is likely the main reason for multiple jobs. Separate jobs give you the ability to schedule workloads around business requirements and, just as importantly, around your infrastructure.
Retention Requirements
Another obvious one, but not all jobs require the same retention period.
Backup Repo Selection
It’s possible you are not using a SOBR and want to store backups in separate locations. You could have critical backups going to a faster repository or storage as well if you wanted to manually configure it like that. A copy job would allow them in both locations, but multiple backup jobs gives you additional flexibility.
You may want to choose a specific repo based on Performance, Capacity, Location, Cost, or any other reason you can think of.
Application aware backups
This is an area where I often separate my jobs based on function. DC’s, Email servers, SQL servers require App Aware settings and often permissions associated with them that are not required in other backups.
Guest File Indexing
File servers and other VM’s can have indexing turned on to be searchable in Veeam Enterprise, you wouldn’t want this on all of your VM’s if it is not required.
Job Encryption
Based on your requirements, it’s possible not all jobs require encryption to be enabled.
These are the reasons I think are more interesting.
They aren't always mentioned when discussing Veeam job design, but they can become very important once you have a larger or more complex environment.
RBAC requirements
If you are doing SQL backups and want to limit what your DB admins can access, or creating dashboards and reports in Veeam ONE, separating based on permissions is a great way to make your life easy going forward. Add the VM to the appropriate job and you don’t need to do any additional configuration.
Compression and Optimization
This is often overlooked as some VM’s get better compression than others, and there are also settings about how aggressive you want to get with it. There is no point increasing this without a significant payoff in space reduction.
Stun Issues
Have you ever tried backing up an HA pair of servers at the EXACT same time? Have you experienced snapshot-related pauses or latency while doing so that caused the whole application to go down? If not, I don’t recommend it. Depending on the hypervisor, storage, application, and workload, snapshot operations can introduce enough latency or interruption to cause problems for a particularly sensitive HA application. If you have an HA pair where both nodes absolutely should not be processed concurrently, separate jobs with deliberately staggered schedules can give you much more control.
Troubleshooting and Maintenance windows
If you want to disable a few small jobs while doing updates and start them back up, you are not effecting everything. If you have monster backup jobs with many VM’s, that may create more added risk during a maintenance window. When you want to troubleshoot and test, you can often act faster on smaller jobs too. This is especially the case if you need to run an active full.
Reduced Blast Radius
This one is pretty simple an but still worth considering. If you do have an issue when the job fails, it won’t be every VM in your environment and only the ones listed in that job.
SAN/Storage controller Load
This one might affect larger environments. A job with many high change rate VM’s can create a pretty significant I/O spike, separating them is one want to stagger the load. To add to that, having snapshots on those same VM’s in VMware could be a potential issue as well or risk you may want to avoid.
Application Dependency order
You may want to back up specific infrastructure or servers to be backed up after other application servers.
There are many other reasons to consider separating jobs based on your unique business requirements. WAN Bandwidth, Security, RPO’s, Test environments, Reporting and performance a just a few reasons you should think about this.
The key is to gather a list of all your servers to back up, and try to plan well in advance. I always recommend to use the least amount of jobs, while hitting your RTO/RPO and performance targets. Make sure that you are using application aware and indexing where required, as well as your separation for security and access are verified.
Can you put them all in one job? Sure, but if you ask yourself if you should be separating the jobs, the answer is:
“It Depends” 🤣
