Pause Source jobs only works on Backup jobs?

[skrause]

Ok, so I set up our monthly full backup to disk tape job this morning and checked the "Pause source jobs if running" box and started the job off (usually I don't get around to creating the job until the afternoon).

All of our source jobs for our tapes are backup copy jobs.

Lo and Behold, several of the VMs failed because their copy job kicked off while the tape job was running.

Is this a known issue with a planned fix (or was it fixed in 9.5update 2 which I just realize I have not installed yet)?

[Dima P.]

Hi Steve,

Do you have a support case for this issue?

[skrause]

Nope, I didn't open a support case.

I am going to be applying 9.5u2 this afternoon and will run a test job next week to see if the same behavior happens after the update and open a case if it occurs again.

[skrause]

CaseID: 02349130

[JoshuaPostSAMC]

I've encountered a similar thing, although it wasn't that the VM backup failed, but the tape job went into a retry state and almost doubled what it should have backed up because it didn't pause the copy job and it said that the data had changed and needed to be retried.

[skrause]

At this point, from what the support engineer has said, it looks like the issue is that Veeam pauses all backup copy jobs that have a single file chain but has a limit to the number of per-vm chains it can pause at a time. Since I use per-vm chains on all my copy jobs this looks like the culprit. He recommended doubling the hold time.

My test re-run of the job didn't error out yesterday, of course, but I did not overlap the copy intervals in the same fashion so I will have to retry again next week after the new fulls copy over the weekend.

[lyapkost]

Hi Steve.

This is a known issue. If a tape job has a job to per-vm repository as a source and has 'prevent from being interrupted by primary jobs' option enabled, it locks only the chains (VMs) which are being copied to tapes at the moment. Chains which are in 'pending' state are not locked and could be modified by source job. As a result tape job may copy some VMs twice or even fail in some cases. It's recommended to increase 'wait for backup jobs' time and schedule source and tape jobs so that they don't overlap to avoid the issue. It is fixed in the upcoming 9.5 update 3.