Configuration database is corrupted

[JonJR]

We updated to v10 a few days ago. In general B&R is working fine. Now getting the following error for the config backup:

Code: Select all

22/02/2020 10:08:36 PM Error Unable to write to configuration backup file.
22/02/2020 10:08:36 PM Error Processing configuration VeeamBackup at VEEAM-BACKUP\VEEAMSQL2012
22/02/2020 10:08:36 PM Error Compressing database VeeamBackup
22/02/2020 10:08:35 PM Error Configuration database is corrupted.
22/02/2020 10:08:35 PM Error Creating configuration backup
22/02/2020 10:08:35 PM Error Writing data section
22/02/2020 10:08:35 PM Error Saving configuration catalog (9% done)

Normally this backup is to a remote Windows share, have also tried aiming it at a local back repo with the same result.

[JonJR]

Support case #04020521

[JonJR]

Code: Select all

[22.02.2020 21:07:08] <01> Error    Configuration database contains corrupted data (table: Ssh_creds, column: passphrase). (System.Exception)

Ok, looking at the B&R logs, it seems that a recently added SSH username and password was the culprit. Deleting that credential now allows a successful config backup.

Odd that the credential worked fine for its purpose also strange that Veeam / SQL Server couldn't fix the corruption. Would also be nice if that error message from the logs was put into the job email.

[tna]

Hey, Jon,
thanks for the info. We had the same problem and it could be solved by removing a new SSH account.
Greetings,
Tobias

[anthony_b]

Thanks Jon,
We also had the same issue on v10, it was resolved by creating a new ssh credential and deleting the old one.

[DonZoomik]

Had a same case with support, #04318948.
Eventually resolved by recreating (create new, remap to new object, delete old) SSH credentials, we didn't exactly determine which one was broken, we just replaced them in bulk. Support has the database dump so maybe they can do some post-analysis.

Very strange case as all the credentials were being used daily by jobs/components and they worked - just configuration backup kept failing.

[DonZoomik]

About a week ago, Linux FLR started failing because it couldn't find SSH credentials in database. Support fixed it with a SQL statement (#04423439). It just seems to be related to problems with credential handling in database.
Now, configuration backup broke again as I've had to change Linux credentials several times due to another case... ugh. Back to support again. Seems to be related to either of 2 actions

• editing description (changed dummy descriptions from previous credential recreations to real descriptive ones)
• switching from user+root -> root-only -> user+root authentication methods - as required during diagnosis of case.