Tapes Fail when primary backup jobs run

[djohnson88]

I recently move our VBR to a new host and upgraded from Version 11 to Version 12. I copied the configuration and move that to the new host also. I double checked the setting and everything is the same.
My issue is that Our Tape Job stops when the primary jobs run but this never happened on the old host. We did have the option "Prevent this job from being interrupted by source backup jobs" Checked but I removed it because the Backup tape job is continuous and I was preventing the primary job from running. The only thing I can think of is maybe something was changed in the registry but I didn't setup Veeam on the last host so I am not sure. Is anyone else having is issue? I would like to have the primary and backup Tape job running at the same time when scheduled.

[Mildur]

Hi Dell

In v12 we have a known issue where locking mechanism doesn't work as expected for upgraded backup chains. We have a workaround with a registry key starting with P20230412. Make sure you are on the latest build (P20230718) and then implement the following registry key:

Code: Select all

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Name: TapeBackupLocksResolution
Type: DWORD
Value: 0

Best,
Fabian

[stuartmacgreen]

After installing V12 Cumulative Patch P20230718 I experienced the issue with kb4478, at the same time I faced a problem that Tape Backup Jobs, setup as Secondary Target for Backup to Disk jobs would not start, just nothing.
I opened 2 cases - a private fix was issued for kb4478 and installed.
This appeared to fix the issue with the Tape Backup Job (Case 06210213), as I had several days go with Tape Backup jobs working as expected. So I closed the case.
However, 5 days later I find its back again. I can manually start the Backup To Tape job.
The interim workaround fix is to restart the Veeam Backup Server. But its a guess when it will stop working again.

(My backup chains have all been upgraded prior to the Cumulative Patch)

Is THIS registry fix related to my symptoms?

Thanks

[Mildur]

Hello Stuart

Rebooting backup server to get tape jobs running again sounds like a new issue and doesn't look related to the registry key.
Please open a new ticket and reference to the private fix and your two cases. Don't forget to share the new case number. I will move your question to a new topic after you have shared the new case number.

Best,
Fabian

[djohnson88]

Hello Milder,

This registry fix. Does it put the tape on hold then restart it after the Job is done or will the tape continue to run at the same time as the primary job?

[luisgmc]

Hello

(Case #06276566)
Last week after upgrading from V11 to V12 12 P20230718, our TAPE JOB started failing. Applied this workaround but without success. Restarted veeam services without luck, should I reboot the VBR server ?

Kind regards
Luis

[luisgmc]

Hi

Veeam support already answered, the reg key was successfully applied so must be another issue.
We never had the option “Prevent this job from being interrupted by source backup jobs” enabled, neither want to enable it, so let’s wait for further developments.

Regards
Luis (Case #06276566)

[david.domask]

Hi @luisgmc,

Can I ask, why don't you want to enable the option? If you think it prevents the source jobs from running, that is a common misunderstanding.

All that option does is to allow the tape job to retain it's lock on the backup file it needs. Normally, without this option, the Tape job will surrender it's lock if _any_ other job wants the same backup file for any reason, and then just error and stop. With this option however, any other operation requesting this file will have to queue and work on other tasks.

I can't say why you didn't run into the locking conflict like this before v12, but give the option a shot. It has 0 impact on the environment, and I'm pretty sure it will only have a positive result for you.

[luisgmc]

Hi David

Just thought I had replied yesterday , weird, must forgot to hit submit button . Never mind, the option “Prevent this jobs from being interrupted” is the way to go and it’s working, you are totally right , “that is a common misunderstanding” I assume .

Kind regards
Luis

[david.domask]

Hi @luisgmc, no worries,I know everyone has busy schedules

And glad to hear it's working. Indeed, even when I was on T1 I got confused by this at first; though I will submit a request to the technical writers to clarify that point in the User Guide, as seems it's a contentious point.

[Samba222]

Hi David,
i run into the same issue and also "missunderstood" this point in User Guide (until Veeam support explained it) - so, thanks for request to clarify!

Ronald

[stuartmacgreen]

Hello Stuart

Rebooting backup server to get tape jobs running again sounds like a new issue and doesn't look related to the registry key.
Please open a new ticket and reference to the private fix and your two cases. Don't forget to share the new case number. I will move your question to a new topic after you have shared the new case number.

Best,
Fabian

Just to close my issue off, Case 06246425.
A table in the VeeamBackup database was showing excessive rows of data or entries.
Once table cleared, no longer experiencing issue.
Backup To Tape chained and scheduled jobs now running as expected.

[cam99x]

I have just updated to version
12.0.0.1420 P20230718 Of Backup & replication

Used the registery entry above.
then run a tape backup, and run the disk backup again.
The tape backup says displays the message "were changed, retry is required..." and pauses waiting for the disk backup job to complete then it resumes and completes.
Do other people have the same result?

This was only a small test job, not an hours long backup that is what we use in production.
This is without setting "Prevent this job from being Interrupted by source backup jobs" I have raised a ticket with Veeam 03092627 a few days ago