EndpointBackup killing my tape job?

[ekisner]

So, the past while I've been running into a scheduling issue between my endpoint backups and my tape backups. Namely, while I identify issues, I have the tape job disabled and I'm just manually running it daily (a weekly job with incrementals). This has caused overlap with my endpoint backups.

On one hand I can understand the behaviour, since the endpoint backup (as far as I know) is a forever-incremental, but on the other... tape backups of all VMs are way more high priority than an a single endpoint backup. At least in our environment.

Specifically, I'm referring to the following error:
Error: Stopped by job 'Backup Job FAKE-COMPUTER-NAME' (EndpointBackup)

Is there any way to override this so that my tape job will continue running and if needed simply skip the endpoint backup?

[Dima P.]

Hi Erik,

Can you clarify was the said Endpoint's job selected as one of the sources for backup to tape job? Thanks

[ekisner]

Yes, all of our backups go to tape.

The tape job targets the repository, specifically. I don't use endpoint backup for desktops (desktops are easy enough to replace), but for physical servers.

[Dima P.]

So you are backing up VMs and physical Endpoint backups within one tape job, right? Might be a good idea to spread the source files between two tape jobs that would also ensure your VM to tape backups are not affected by the physical ones?

[ekisner]

That would reduce the impact, yes. If I must do that, I will. Probably by moving the endpoint backups to a new repository, then setting up two new tape jobs (GFS style) to back up that repository.

I would inquire though as to why the behaviour is not consistent. If a VM backup is running, the tape job simply skips it and carries on to the next item in the list. If an endpoint job is running, it errors out.

[Dima P.]

I think that’s happening because ‘Wait for the linked backup jobs’ option is misbehaving in the existing version ( it should wait for all the source jobs but it does wait only for the first one in the list). This behavior is corrected in the upcoming version but for now I’d vote for splitting the physical backups and VM backups between two repositories and as a result splitting the tape backups into two separate jobs.

[ekisner]

Well, if a fix is in the works with the upcoming version, that's perfectly good for me. Thank you Dmitry, both for advising of the upcoming fix and for providing a workaround. Appreciate it