The job chaining feature was released in version 6.5 of Veeam Backup & Replication. The primary purpose of this feature is to take away the guesswork on job start times for consecutive iteration. This is especially important if one backup job needs to be completed before the next backup job begins, but exact timing isn’t known. This feature is defined in the schedule option of the backup job wizard, as shown in the figure below:
I recently came to the realization that this scheduling option to chain jobs can also be used to answer a very important question: What job configuration is best for my environment?
What job configuration is best for my environment?
There are a number of backup job options for VMware and Hyper-V VMs. In fact, the processing engine is the same between the two hypervisor platforms; the only difference is the source data and how the proxies access it. But the options in the backup job are a great way to tweak and tune your VM backup infrastructure to your needs.
Options such as forward or reversed incremental backups, compression, deduplication, transformation of rollbacks and different backup repositories all make material differences in the speeds and feeds of your VM backup infrastructure.
In my recent situation, I wanted to see how a particular VM backed up from a performance and I/O perspective with a number of different options:
- Forward vs. Reversed incremental
- Deduplication and compression on vs. Deduplication and compression off
- One backup repository vs. another backup repository
- One transfer mode vs. another transfer mode (Hot-add vs. Direct SAN, for example)
- Physical proxy vs. Virtual proxy
You can see that these are all interesting scenarios, and the job chaining feature can help you find out how jobs will differ in your environment. Basically, you can set up a job with each option, and schedule them to chain after one another.
The important thing to be aware of here is to ensure that they all pick up the same change rate profile. The easiest way to do that is to back up one or more test VMs that are powered off. After your test backups are completed, boot up the test VMs and ingest some data on them to introduce a change to the virtual disks. Before you run your test backups again, shut down the VMs so your test backups all pick up the exact same change rate profile.
Using the job chaining feature coupled with reviewing logs for timing, transfer amounts and read/write rates, you can really provide insight into your specific configuration so that you know how to tune your backups.
Have you ever found a need to use the job chaining feature in another way? If so, share your use case below.