Reason for Job Chaining

[mkaec]

I've seen it mentioned in the past that job chaining is frowned upon and a request was made for us to post use cases so that it could be understood why chaining was needed when the scheduler should be able to take care of things. I have several jobs chained and here is why.

The chained jobs all target the same Hyper-V VM. It is a large file server. The data is split up on separate virtual disks and each job backs up a different virtual disk. The reason this is done is because some data gets backed up to one repository and some to another. Additionally, different retention settings are applied to data from different disks. The active full schedule is also staggered so different disks are on different nights.

So far, none of what I wrote has anything to do with chaining. If I let all the jobs run at once, B&R's scheduler does a good job of making sure that only one job is running at a time. However, there is a problem caused by checkpointing. Sometimes when a job starts, the checkpoint from the prior job has not finished merging and the starting job sees the checkpoint disks. Then, when the merge completes, the checkpoint disks are deleted and the job fails because a disk disappeared. Here is a typical error message:

Code: Select all

1/10/2018 12:30:36 AM :: Processing <SERVER> Error: The system cannot find the file specified.
Failed to open file [E:\Virtual Machines\Disks\<DISKNAME>_6F6F8E98-F7D7-4A72-AC29-F4FBA5ADF660.avhdx] in readonly mode.
Failed to open VHDX, disk path: 'vhdx://<shadowSpec><extent path="E:\Virtual Machines\Disks\<DISKNAME>.vhdx" shadow="E:\Virtual Machines\Disks\<DISKNAME>.vhdx" isAutoRecovery="False" /><extent path="E:\Virtual Machines\Disks\<DISKNAME>

So, to work around this problem, the jobs are chained and each job runs a pre-script that waits for the merge to complete before starting.

[foggy]

Thanks Marc, sounds reasonable. In this case jobs chaining allows to avoid issues.