Backup configuration file, reading xml

[McKITGuys]

Hi all,

I am still in the planning stages to rebuild our VBR server - one of the reasons for a total rebuild is because have had trouble with licensing failing and even with supports help, we could not get to the bottom of it. Somehow there are some old servers/old IPs hanging around and somehow VBR picks them up and assigns a socket and then my "real jobs" fail as no socket licenses left. Have tried every which way between support and myself to figure out why this happens.

I got reading about the backup configuration file (.bco) that is stored and it said it is in XML. Is there any way I can open this and extract the xml blocks to see if it gives me a clue where these bad IPs come from? If I could solve that, I probably would not have to rebuild the server.

TIA

[HannesK]

Hello,
can you please provide the support case number? That problem should be solvable.

I got reading about the backup configuration file (.bco) that is stored and it said it is in XML.

can you maybe provide the link / source where you read that? That needs to be fixed than.

The configuration backup is a SQL database dump.

Best regards,
Hannes

[McKITGuys]

This came from the manual "Veeam Backup and Replication, User Guide for VMware vSphere" dated Dec 2022, pg 723 under "Configuration Backup Files". I will have to dig up the case number as it is now a few months old. Will follow up with another post then.

When you perform configuration backup, Veeam Backup & Replication retrieves data for the backup server from the configuration database, writes this data into a set of XML files and archives these XML files to a backup file of the BCO format.

[McKITGuys]

Case number 05394855. I will have to log in to other portal to see when we closed it. But basically we seemed to be at a dead end trying to resolve it and I just figured I would have to rebuild from scratch to get rid of the problem.

[HannesK]

hmm I see... I will check that. In any case: editing anything in there is like editing the database. you could do that directly without configuration backup.

As the case is pretty old, there is nothing I can do about it. My suggestion would be to open a new case. Provide logs and database and ask support to fix it.