SQL Log backup

[PenguinSSH]

We just did an upgrade of our Veeam 8 environment to Veeam 9 and have it only 1 issue so far.

One of our Hyper-V job (the other 4 are working) is processing SQL log backups periodically. It seems that it is unable to locate a backup with a certain ID.

Error: Unable to get backup with id '3784a4d1-f4ff-4025-9e73-17a6e45e287f'

Thing is, if we change this to truncate log and run the backup job, it seems to truncate the logs properly. We can see the recovery point and everything else.

If we change this back after a backup, to periodic SQL log backups, the SQL backup job task always spawns and ends with this error.

Any ideas?

[nielsengelen]

This looks like it might be an issue within our database however it is advised to open a support case so it can be resolved.

[PenguinSSH]

Ok will do!

EDIT: FYI, caseID: 01400178 I'll report from here with findings to help others.

[josh31]

Any word on this one? I have the same issue. I just opened a case (01671453).

[kte]

Any news on this I have the same issue in VMWare.
Just creating the case now, but the log collection thakes a while

[MP230]

Same issue here, does it make sense to open another case related to this now "known" issue?

[veremin]

It's worth doing that indeed, until the issue is confirmed (or not) to be a known one. Also, you might want to make a reference to the cases provided above. Thanks.

[PenguinSSH]

Hello to all,

Just to let you know that we ended up closing the call without Veeam support. It looks like they had some work to do in the database to resolve those issues so I suggest you contact them to resolve this.

As for us, since the SQL servers were relatively small, we ended up doing the following. (500GB)

• Clone the job
• Delete the other job that is not working
• Rename the clone job
• Rename the old job folder in the backup repository and keep the old one until backup retention expires
• Re-run the backup causing it to do a new backup chain
• Enable SQL periodic backups in the job (Takes care of logs)

Upon doing this, this resolved all issues we had even the periodic SQL log backups. So if you need a quick fix, you can do the following. Otherwise you can contact Veeam support and they'll fix the database backup ID that is missing or not linked properly.

Please note that we did have 5 other SQL jobs with the same settings but none of them have problems and all of them worked perfectly during our restore tests.

We did the following because we were not confident enough with database modification and the restore procedure that follows this is required. We preferred starting fresh for this job as to ensure we did not have other problems down the road.


Other than this one issue, I must say that we did not experience any other problems since the upgrade so this is by far the most stable release we have upgraded to so far across all products that we use!

Cheers

PS.: I'll come back here periodically if there is any questions I can answer.

[MP230]

It's worth doing that indeed, until the issue is confirmed (or not) to be a known one. Also, you might want to make a reference to the cases provided above. Thanks.

Case ID = 01672174

[kte]

can you remap the backups and copy jobd

[PenguinSSH]

We haven't tried that honestly but I think it was pointing to something inside the database and not the job mapping.

[kte]

I also have if i want to delete somthing from the database, an imported backup or something, veeam 9 say that a backup job or SQL log shipping job is still running and he can't delete it

[kte]

seems to be working if you clone the job and remap it again and after a reboot of the servers the delete from database from and imported job seems to work also