Get-VBRSureBackupJob not working after P20230718 CU

[billcouper]

After installing the P20230718 CU for VBR12, the Get-VBRSureBackupJob cmdlet no longer appears to function. If I run "Get-VBRSureBackupJob" without any parameters, it fails.
Case #06273988

Get-VBRSureBackupJob : Unable to get backup with id 'e2a7c53d-e80a-478c-82f8-ed565c65b891'
At line:1 char:1
+ Get-VBRSureBackupJob
+ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-VBRSureBackupJob], Exception
+ FullyQualifiedErrorId : System.Exception,Veeam.Backup.PowerShell.Cmdlets.GetVBRSureBackupJob

[Mildur]

Hi Bill

Please keep working on this issue with our customer support team. They requested a log package from your backup server.
The command works fine in my P20230718 lab:



Best,
Fabian

[billcouper]

ty Fabian. I sent the requested logs to the support ticket.

Interestingly, I checked the bjobs table in the vbr database using pgadmin and I don't see any job with the ID mentioned in the cmdlet error output. Also... I can't even target specific jobs by name... eg "Get-VBRSureBackupJob -Name SbJobName"... it just complains it can't find that same job id that doesn't exist.

[Mildur]

Hi Bill

Thank you.
I believe, it doesn't look for a specific backup job id. The error message is telling us, that no backup with that ID was found. Backup Job and Backup are two different entities in the database.
On PowerShell you can query backups with Get-VBRBackup.

Best,
Fabian

[billcouper]

Ah. Whoops. I thought it was referring to a backup job ID and not a specific backup.

If I look in the backup.model.backups table that ID doesn't exist. Indeed, if I search the entire database that ID does not exist anywhere in the database.

[david.domask]

Hi @billcouper,

Very likely either this is being stored in an XML somewhere or it's being referenced in a place that just wasn't caught by your query; I've added some notes to the case for the engineer as very likely it's something in the LinkedJobs/LinkedBackups tables or it's in the SBVerificationRoles table, but the engineer will check these also.

[sameproblem]

Hi I've got the same problem, is there a solution yet?

Thx

[david.domask]

Hi @sameproblem, regrettably the error alone isn't enough for us to tell the specific issue, and it will need review by Veeam Support.

When you open a support case, please be sure to include:

1. Logs from the VBR server after reproducing the issue (note the date/time of the test and the username that launched Powershell to test): https://veeam.com/kb1832 Use the 3rd option, and select the Veeam Server
2. Configuration Database Backup if your data-export policies allow it: https://www.veeam.com/kb1471 (if your policies do not allow it, it's not a huge deal, Support can check other ways)

Be sure to post the case number here when you get it (should begin with 06* for the case number as of this post)

[billcouper]

@sameproblem and potentially others.... I was able to resolve the issue by recreating every SureBackup application group from scratch. Bit of a PITA but worked
1. Edit SB jobs and set 'no application group'
2. Delete and recreate all application groups
3. Edit SB jobs and reassign correct application group

[sameproblem]

Thanks!
The problem was: there were backups in some application groups which no longer existed. Removing them from the appgroup solved the problem instantly.

[Lance-a-lot]

Got same issue here (on P20230718), I tried the above but still getting the error.

I've now removed all application groups, deleted the SureBackup jobs (going to be fun setting those back up) and also removed the backups from configuration and re-scanned to no avail. I can't even create a new Application Group now.

Logged with support, Case # 06329298

[billcouper]

For us, we had no change in backups - all application groups were using existing and available backups... and we have dozens of app groups, it would have been very unusual for all of them to suddenly have a backup no longer existing at the same time, without other very noticeable "explosion" in the environment. Add sir lancelot's experience to the mix and there could be multiple different causes for this issue.

I hope you get your problem solved Lance-a-lot and please post here what was the fix?

[Lance-a-lot]

Looks like I've hit a snag,

Long story short and probably moving away from the original post, I have two data centres, Data Centre (A) contains the production environment, Data Centre (B) is the DR/Failover site, we use storage replication as the backup source meaning backups are written to disk in Data Centre (B), to complicate matters we have two primary B&R instances, one covers our general production estate, the second is covering our SQL estate, we have the second instance so that we can delegate access to the dba's (VES doesn't have the full SQL explorer feature set).

I setup a third B&R instance in Data Centre (B), which imports the backups from both instances and then runs the SureBackup jobs to simulate if Data Centre (A) had failed.

This has been running fine for the last year and has been a useful tool for testing, assurance and compliance, but recently stopped working due to the error mentioned in this thread.

I've come back to an email this morning from Support saying this configuration is unsupported and I have to run my SureBackup jobs from the primary servers, this creates a problem due to the two primary B&R instances, i.e. Domain Controllers/App Servers on instance 1, and SQL backend servers on instance 2 and these instances are isolated from the test/dev environment in Data Centre (B).

I'm not writing data to the repositories on my SureBackup instance, its simply an import to give the assurance that a failure in the primary DC we can import our backups and restore as required.

I'm slightly confused why this not longer works, and can only think its related to either the recent backup chain upgrade to "true per-vm" or the recent patch to P20230718.

I'll reply to support, but think I've hit a wall with the unsupported config.