After BBS upgrade to v2.17.9, all historic backups are gone

[edersong]

Description

After BBS upgrade to v2.17.9, all historic backups are gone.
No backups are being listed for restore, even new backups.

Steps to Reproduce

1- Do a backup with a new version
2- Try to recover any old backup.

Installation Type

Docker

BBS Version

v2.17.9

Agent Version (if applicable)

v2.17.9

Agent OS (if applicable)

Windows

Relevant Logs

Nothing is being reported on logs

[Delver26]

Can confirm I'm seeing the same issue. No historic backups available, and new backups are completing as normal but not being displayed on the UI. I can see backups are being created on the disk.
catalog_rebuild and repo_repair also seem to have no effect.

[marcpope]

Root cause identified and fixed in commit 3f4ea04.

The bbs-ssh-helper borg-list command used 2>&1, which merged borg's stderr warnings into the JSON stdout. When borg emitted any warning (exit code 1 — e.g., stale cache after a container restart), json_decode returned null. Both the post-prune archive sync (runs after every backup) and catalog_sync interpreted this as "zero archives exist in borg" and deleted all archive records from the database.

The fix:

1. Removed 2>&1 from borg-list so JSON output stays clean on stdout
2. Added JSON validation guards in both the post-prune sync and catalog_sync — if the JSON parse fails, the sync is now skipped (prune) or the job fails (catalog_sync), instead of silently deleting all archives

To recover after upgrading:
After pulling the fix, trigger a Catalog Sync from the repository detail page (Actions → Catalog Sync). This will re-read all archives from borg and repopulate the database. Your backup data on disk was never affected — only the database records were lost.

[marcpope]

Please make sure you get 2.17.11, there was an issue in 2.17.10 that I found after testing.

[edersong]

Upgraded to 2.17.11, didn't find any Actions → Catalog Sync option, so tried Rebuild Catalog --> Rebuild full, but older backups are still missing and, now Size field in Clients dashboard are showing -- instead of the backup's size.

[marcpope]

@edersong I need more sleep! The Rebuild Full button was broken for this scenario — it was only rebuilding the file browse catalog from the (already empty) archives table, not re-reading from borg. Fixed in 6831410.

After upgrading, go to the repository detail page and click Rebuild Full again. This time it will:

1. Run borg list against your actual repo on disk
2. Repopulate the archives table with all recovery points (including sizes via borg info)
3. Auto-queue a file catalog rebuild

Your backup data on disk was never affected — this just restores the database records.

[edersong]

Thank you for the update!
Upgraded to the lastest version and tried to run Rebuild Full task, but it's reporting the following error:

Catalog sync failed: borg list output was not valid JSON (possible stderr contamination)

[marcpope]

@edersong The error message was hiding the actual cause — we've updated it to show what borg actually reported. Can you upgrade again and retry Rebuild Full? The error should now show the real reason (e.g., wrong passphrase, repo path issue, permission error, etc.) which will help us fix it.

If you're building locally: docker compose build && docker compose up -d
If pulling from Docker Hub: we'll need to push an updated image — can you share the new error message after upgrading?

[edersong]

Done!
It now reports the following:

borg list output was not valid JSON: Error: repo path must be under /var/bbs/ or a registered storage location

[marcpope]

@edersong Thanks for the error output — that pinpointed it. The file /etc/bbs/allowed-storage-paths (which tells bbs-ssh-helper that your NAS mount path is allowed) lives inside the container filesystem and was lost every time the container was recreated during an upgrade. It was never being regenerated on startup.

Fixed in v2.17.14 — the entrypoint now regenerates this file from the database on every container start. Please upgrade and retry Rebuild Full:

docker compose pull && docker compose up -d

Then go to the repository detail page and click Rebuild Full again. This time it should be able to access your NAS-mounted repos and recover all your archive records.