Listing latest archive with multiple repositories conifgured only works for first one #706
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
I've got machines sending backups to multiple repositories and wanted to set up some monitoring for them. Only the archive information for the first one is shown.
Steps to reproduce (if a bug)
Include (sanitized) borgmatic configuration files if applicable.
After backups:
Note the lack of output for the secondary / tertiary repository. Also empty in the JSON output.
Expected output would be more like this:
Actual behavior (if a bug)
Latest archive on first repository only is shown / represented in output/json.
Expected behavior (if a bug)
Latest archive on each repository is shown / represented in output/json.
Other notes / implementation ideas
My guess would be that the "latest" archive information is cached based on what's found on the first repository, and also tried to be shown from the second and third repository - instead of being refetched.
Environment
borgmatic version: [version here]
1.7.13borgmatic installation method: [e.g., Debian package, Docker container, etc.]
https://docs.mailcow.email/third_party/borgmatic/third_party-borgmatic/
Borg version: [version here]
borg 1.2.4Python version: [version here]
Python 3.11.2Database version (if applicable): [version here]
mysql Ver 15.1 Distrib 10.6.13-MariaDB, for Linux (x86_64) using readline 5.1 coperating system and version: [OS here]
Alpine 3.17.3Thanks so much for taking the time to file this. I have confirmed the behavior you're seeing, and I believe a similar problem occurs with the
listaction as well. Runninginfowith--verbosity 2, it does look like borgmatic is passing the exact same archive name to the commands for each repository. So that will need to be addressed to solve this.This is fixed in main and will be part of the next release. (The problem turned out not to be an intentionally cached value, but rather accidental caching due to code overwriting a value at global scope.) Thanks again!
wow, that was a quick turnaround - thank you very much! :)
Just released as part of borgmatic 1.7.14!