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.

[FireExit]

I was getting a similar thing in Veeam 11, upgraded to 12.2 and still happening. Logs show it's failing to backup the configuration database, on a password row, claiming the database is corrupted:

Code: Select all

Failed to save database row (table Credentials, field password, value Veeam.Backup.Configuration.V80.PlainPasswordFieldValue). (System.Exception)
at Veeam.Backup.Configuration.V120.XmlWriterProvider.SaveData(Row row)
...
Configuration database is corrupted.
...
Unable to write to configuration backup file. (Veeam.Backup.Common.VeeamException)

Raised support case #07459339 ; adding it here for the internet to find and index the errors, and for Veeam people to see it's still happening in the latest version.

[Mildur]

Hi FireExit,

I'm sorry to hear that you have faced an issue with configuration backup. Our customer support team will forward any "technical issues" they observe with our product directly to R&D.
Please note that, even if the error message appears to be similar, it doesn't mean it shares the same root cause as discussed in this 4-year-old topic.

Thank you,
Fabian

[FireExit]

Hi Mildur,

Thank you; support asked me to re-enter all the credentials and now it works again; which is reasonable but won't give anything to forward to R&D or explain what went wrong.

As I was updating them and saving, one standard one (i.e. not SSH; used for SMTP relay of notifications) gave a popup "Key not valid for use in specified state" and after that the configuration backup worked. There was no hint why that one was a problem, I looked in the database before - it had a BASE64 blob with the same prefix and similar length to the other passwords.