Possible issue with server definition

[GDowning14]

Hi,

Today I ran into an issue with the definition of the backup server. I am not reporting this via the normal bug report channel as I did not gather adequate artifacts or sufficient documentation to attach to bug report (not to mention that it is also probably a self-inflicted issue). This is more just for general awareness.

When reorganizing the home lab, I renamed the the host on which the Borg server software runs. I also updated the Settings->General->Server Host/IP to point to the new server name. After this change was completed, I realized the new server name was being passed through a reverse proxy which ended up breaking the backup as the proxy was playing with certificates and also redirecting to the wrong ports. After straightening out that mess, I found that all backups were failing as they had invalid borg server host/path specifications due to the fact that the host name portion of the path was duplicated.

For example: When backing up to the "MyWorkstation" repository on the "backup.mydomain.com" borg backup server, the borg command line included "ssh://bbs-MyWorkstation@backup.mydomain.com//backup.mydomain.com///mnt/Backups/10/MyWorkstation:...". All attempts to repair this damage using the Settings->General->Server Host/IP were unsuccessful. Changes on the Settings screen would replace the first occurrence of the host name but not the second. Again, for example, placing an IP on this screen resulted in "ssh://bbs-MyWorkstation@192.168.x.x//backup.mydomain.com///mnt/Backups/10/MyWorkstation:...". This was also visible on the Repository set up for each client. When looking at the "Repository Info" tab for a client repository, instead of seeing a path like "/mnt/Backups/10/MyWorkstation", I would see "backup.mydomain.com///mnt/Backups/10/MyWorkstation".

I eventually repaired this by using MySQL to edit the values in the repositories.path database field and strip out the unwanted host names and restore the proper paths. Besides this repair, are there other related data items/configurations that I should also be checking? Is there a better way to manipulate the repository path values?

Let me finish by saying that I have been using BBS for quite a while now and this is the first issue I have encountered while using this product. I am very impressed with its reliability, ease of use, and overall professional polish. Keep up the good work!

Thanks!

[marcpope]

Thanks for the detailed write-up, and sorry it took me a while to get to this.

Older versions accepted a server host with a scheme, like https://backup.mydomain.com. That value went into the repo paths as-is, and on the next host change only the https: part was replaced, which left //backup.mydomain.com stuck in every path. Changing the setting again couldn't clear it.

Two fixes in cf8f053, shipping in the next release:

• Changing the server host (globally or per client) now replaces the whole host part of the path, including any leftover junk.
• The update runs a one-time repair that rewrites any path still carrying a duplicated host, so nobody has to edit MySQL.

Your manual fix was the right one. The repo path is the only place the host is stored; agents get the server host from BBS each time they connect, so there's nothing else to check. Settings now also rejects hosts with http:// or a path, so this can't happen again.