borgmatic-collective/borgmatic

Watch

Fork 57

`--repository` Filter is not applied to commands #1176

New issue

Closed

opened 2025-11-02 15:23:19 +00:00 by margau · 3 comments

margau commented

2025-11-02 15:23:19 +00:00

What I'm trying to do and why

I've recently migrated to borgmatic 2.x, and therefore reformated the hook scripts.

I'm using a hook to inform me of a successfull backup via the following hook:

commands:
    - after: action
      when:
          - create
      states: 
          - finish
      run:
          - promtext /var/prometheus/borgmatic_{backup_name}.prom borgmatic_success_time $(date +"%s") --label backup_name={backup_name} --label hostname={hostname} --label repository={repository} --label repository_label={repository_label}
          - promtext /var/prometheus/borgmatic_{backup_name}.prom borgmatic_error 0 --label backup_name={backup_name} --label repository={repository} --label hostname={hostname}

This should obviously only run, when a backup for a given repository was finished (and did in 1.x with after_backup, see https://margau.net/posts/2024-08-02-borgmatic-prometheus/

Now, when I run a filtered borgmatic action with default actions (failure on repo1 is intended), the "create finish action" runs for the other two repos in the config file too:

~# borgmatic create -v1 --repository repo1
repo1: Running before create action command hook
repo1: Creating archive
Failed to create/acquire the lock (...) (timeout).
repo1: Error running actions for repository
repo1: Command 'borg create (...)' returned non-zero exit status 2.
repo3: Running before create action command hook
repo3: Running 2 commands for after create repository hook
repo2: Running before create action command hook
repo2: Running 2 commands for after create repository hook
(...)

It seems that the --repository-filter is only applied to the actual actions, but not the hooks.

If I understood the docs correctly, I'd expect that the commands for repo2 and repo3 would never run for the filter --repository repo1.

If this is the case, it is probably dangerous, because it could create a "backup was successfull"-command when no backup was actually tried for this repo.

Steps to reproduce

In the config files, repo1, repo2 and repo3 are configured.

Also, an "after create finish"-action is configured (see above)

Actual behavior

Commands are also being executed for repo2 and repo3

repo3: Running actions for repository
repo3: Running before create action command hook
repo3: promtext /var/prometheus/borgmatic_default.prom borgmatic_start_time $(date +"%s") --label backup_name=default --label hostname=(censored) --label repository=ssh://(censored) --label repository_label=repo3
repo3: Running 2 commands for after create repository hook
repo3: promtext /var/prometheus/borgmatic_default.prom borgmatic_success_time $(date +"%s") --label backup_name=default --label hostname=(censored) --label repository=ssh://(censored) --label repository_label=repo3
repo3: promtext /var/prometheus/borgmatic_default.prom borgmatic_error 0 --label backup_name=default --label repository=ssh://(censored) --label hostname=(censored)
repo2: Running actions for repository
repo2: Running before create action command hook
repo2: promtext /var/prometheus/borgmatic_default.prom borgmatic_start_time $(date +"%s") --label backup_name=default --label hostname=(censored) --label repository=ssh://margau@cembra.16.wlandt.de:2222/home/margau/borg/host1.het.fsn.de.as213204.net-default --label repository_label=repo2
repo2: Running 2 commands for after create repository hook
repo2: promtext /var/prometheus/borgmatic_default.prom borgmatic_success_time $(date +"%s") --label backup_name=default --label hostname=(censored) --label repository=ssh://(censored) --label repository_label=repo2
repo2: promtext /var/prometheus/borgmatic_default.prom borgmatic_error 0 --label backup_name=default --label repository=ssh://(censored) --label hostname=(censored)

Expected behavior

No commands run for repo2 and repo3

Other notes / implementation ideas

No response

borgmatic version

2.0.10

borgmatic installation method

pipx

Borg version

borg 1.2.4

Python version

Python 3.11.2

Database version (if applicable)

No response

Operating system and version

Debian GNU/Linux 12 (bookworm)

### What I'm trying to do and why I've recently migrated to borgmatic 2.x, and therefore reformated the hook scripts. I'm using a hook to inform me of a successfull backup via the following hook: ``` commands: - after: action when: - create states: - finish run: - promtext /var/prometheus/borgmatic_{backup_name}.prom borgmatic_success_time $(date +"%s") --label backup_name={backup_name} --label hostname={hostname} --label repository={repository} --label repository_label={repository_label} - promtext /var/prometheus/borgmatic_{backup_name}.prom borgmatic_error 0 --label backup_name={backup_name} --label repository={repository} --label hostname={hostname} ``` This should obviously only run, when a backup for a given repository was finished (and did in 1.x with `after_backup`, see https://margau.net/posts/2024-08-02-borgmatic-prometheus/ Now, when I run a filtered borgmatic action with default actions (failure on repo1 is intended), the "create finish action" runs for the other two repos in the config file too: ``` ~# borgmatic create -v1 --repository repo1 repo1: Running before create action command hook repo1: Creating archive Failed to create/acquire the lock (...) (timeout). repo1: Error running actions for repository repo1: Command 'borg create (...)' returned non-zero exit status 2. repo3: Running before create action command hook repo3: Running 2 commands for after create repository hook repo2: Running before create action command hook repo2: Running 2 commands for after create repository hook (...) ``` It seems that the `--repository`-filter is only applied to the actual actions, but not the hooks. If I understood the docs correctly, I'd expect that the commands for repo2 and repo3 would never run for the filter `--repository repo1`. If this is the case, it is probably dangerous, because it could create a "backup was successfull"-command when no backup was actually tried for this repo. ### Steps to reproduce In the config files, `repo1`, `repo2` and `repo3` are configured. Also, an "after create finish"-action is configured (see above) ### Actual behavior Commands are also being executed for repo2 and repo3 ``` repo3: Running actions for repository repo3: Running before create action command hook repo3: promtext /var/prometheus/borgmatic_default.prom borgmatic_start_time $(date +"%s") --label backup_name=default --label hostname=(censored) --label repository=ssh://(censored) --label repository_label=repo3 repo3: Running 2 commands for after create repository hook repo3: promtext /var/prometheus/borgmatic_default.prom borgmatic_success_time $(date +"%s") --label backup_name=default --label hostname=(censored) --label repository=ssh://(censored) --label repository_label=repo3 repo3: promtext /var/prometheus/borgmatic_default.prom borgmatic_error 0 --label backup_name=default --label repository=ssh://(censored) --label hostname=(censored) repo2: Running actions for repository repo2: Running before create action command hook repo2: promtext /var/prometheus/borgmatic_default.prom borgmatic_start_time $(date +"%s") --label backup_name=default --label hostname=(censored) --label repository=ssh://margau@cembra.16.wlandt.de:2222/home/margau/borg/host1.het.fsn.de.as213204.net-default --label repository_label=repo2 repo2: Running 2 commands for after create repository hook repo2: promtext /var/prometheus/borgmatic_default.prom borgmatic_success_time $(date +"%s") --label backup_name=default --label hostname=(censored) --label repository=ssh://(censored) --label repository_label=repo2 repo2: promtext /var/prometheus/borgmatic_default.prom borgmatic_error 0 --label backup_name=default --label repository=ssh://(censored) --label hostname=(censored) ``` ### Expected behavior No commands run for repo2 and repo3 ### Other notes / implementation ideas _No response_ ### borgmatic version 2.0.10 ### borgmatic installation method pipx ### Borg version borg 1.2.4 ### Python version Python 3.11.2 ### Database version (if applicable) _No response_ ### Operating system and version Debian GNU/Linux 12 (bookworm)

witten commented

2025-11-02 18:27:27 +00:00

Owner

Thanks for taking the time to file this and provide all the details. I haven't had a chance to dig into this yet, but I have managed to reproduce the behavior you're seeing, and I agree that it seems pretty non-intuitive!

👍 1

witten added the

bug

label

2025-11-02 18:27:33 +00:00

witten referenced this issue from a commit

2025-11-03 03:32:28 +00:00

Fix the "--repository" flag not applying to command hooks (#1176).

witten commented

2025-11-03 03:32:53 +00:00

Owner

Okay, this is fixed in main and will be part of the next release. Thanks again for bringing this to my attention!