Start BCJ / S3 Offload only after main job retries are done

[kewnev]

Hello,

We are having an issue with backups where sometimes a backup of a specific VM will fail, which would then normally backup fine upon the next retry. However what happens is that because the linked BCJ or S3 Offload job starts immediately after the main backup, the failed VMs fail again during retry because the BCJ / S3 Offload has the VBK/VIB file open, preventing the main job retry from writing to it.
Is it possible to make it so that the BCJ / S3 Offload will only start after all retries have been attempted?

(Note, the initial failure is due to random VSS issues which I will look at resolving separately. For now I just want to ensure that the retries work and are not being blocked).

Many Thanks.

[Mildur]

You could configure the s3 offload window as a workaround. Configure it to a time window, where no backup or copy jobs are running.

For BCJ, there is a similar config.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Click Window and specify when it is allowed or prohibited to move or copy data to object storage.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[kewnev]

Thanks for the workaround, but the problem with that method is that we are then making guesses as when is a good time to start the S3 offload / BCJ. It would be nice if they could instead just wait until retries are done before they initiate. I thought maybe a way around it was to set a 0 minutes wait until each retry attempt so that the retry would immediately start before the S3 offload / BCJ kicked in. However a 1 minute wait seems like the minimum. Another way around it would be to delay the BCJ / S3 offload for a certain amount of time after a new restore point is detected. We could do so with BCJ by placing a sleep delay in the pre-job script. However there doesn't seem to be a pre-job script for offloads. Is there some way to delay the S3 offload / BCJ from running once it detects the existence of a new restore point? Maybe some type of registry entry.

[veremin]

a backup of a specific VM will fail, which would then normally backup fine upon the next retry. However what happens is that because the linked BCJ or S3 Offload job starts immediately after the main backup, the failed VMs fail again during retry because the BCJ / S3 Offload has the VBK/VIB file open, preventing the main job retry from writing to it

This does not sound right to me. Neither backup copy nor Capacity Tier offload job should copy the incomplete restore points and lock backup files due to that. So may I ask you to open a ticket with our support team and provide its number here? Thanks!