before_everything errors notifications #821

New issue

Closed

opened 2024-01-27 16:08:40 +00:00 by josephswan · 3 comments

josephswan commented

2024-01-27 16:08:40 +00:00

What I'm trying to do and why

Hello, devs.

What is the logic/problem behind not firing the on_error hook or Apprise (or other) fail: notification in case of errors in before_everything hook?

I'd like to make some preparations (like dumping LUKS headers, backing up my local services running in containers, etc.) only once, and then do the actual backup into multiple repositories (local + offsite). Seems like the before_everything (and the cleanup in after_everything) is what I need. What is a proper way to be notified about errors on those steps?

Should I rely on the scheduling app (systemd timer in my case) to get the notifications? Wouldn't it be more convenient to have all notifications settings in one place (in the borgmatic itself)?

### What I'm trying to do and why Hello, devs. What is the logic/problem behind not firing the `on_error` hook or Apprise (or other) `fail:` notification in case of errors in `before_everything` hook? I'd like to make some preparations (like dumping LUKS headers, backing up my local services running in containers, etc.) only once, and then do the actual backup into multiple repositories (local + offsite). Seems like the `before_everything` (and the cleanup in `after_everything`) is what I need. What is a proper way to be notified about errors on those steps? Should I rely on the scheduling app (systemd timer in my case) to get the notifications? Wouldn't it be more convenient to have all notifications settings in one place (in the borgmatic itself)?

witten commented

2024-01-27 17:40:17 +00:00

Owner

Thanks for filing this!

What is the logic/problem behind not firing the on_error hook or Apprise (or other) fail: notification in case of errors in before_everything hook?

There's no fundamental reason that on_error couldn't trigger whenbefore_everything errors. The main reason it doesn't happen now is incidental: The on_error hook currently triggers on a per-configuration basis, and before_everything happens before the main processing for each configuration file. But it could in theory be altered to trigger on_error.

As for Apprise hook's fail: notification getting triggered, it's the same reason: before_everything happens well before all that Apprise logic kicks in. That could also be changed.

Should I rely on the scheduling app (systemd timer in my case) to get the notifications? Wouldn't it be more convenient to have all notifications settings in one place (in the borgmatic itself)?

As a work-around until this is implemented, yes, you could relying on systemd to notify you of errors.

Thanks for filing this! > What is the logic/problem behind not firing the on_error hook or Apprise (or other) fail: notification in case of errors in before_everything hook? There's no fundamental reason that `on_error` couldn't trigger when`before_everything` errors. The main reason it doesn't happen now is incidental: The `on_error` hook currently triggers on a per-configuration basis, and `before_everything` happens *before* the main processing for each configuration file. But it could in theory be altered to trigger `on_error`. As for Apprise hook's `fail:` notification getting triggered, it's the same reason: `before_everything` happens well before all that Apprise logic kicks in. That could also be changed. > Should I rely on the scheduling app (systemd timer in my case) to get the notifications? Wouldn't it be more convenient to have all notifications settings in one place (in the borgmatic itself)? As a work-around until this is implemented, yes, you could relying on systemd to notify you of errors.

witten commented

2025-03-12 21:31:08 +00:00

Owner

So rather than make the before_everything/after_everything hooks trigger the on_error hook (and Apprise), I ended up adding a new hook type that triggers an error hook (and Apprise) as necessary. This required refactoring the way that hooks work, both under the hood and at the configuration file level. Documentation is here: https://torsion.org/borgmatic/docs/how-to/add-preparation-and-cleanup-steps-to-backups/

The new hook type is a configuration hook, and it runs at the scope of a whole configuration file... in other words, before and after all actions and repositories in that configuration file. Hopefully that works for your use case.

This is implemented in main and will be available in the next release.

So rather than make the `before_everything`/`after_everything` hooks trigger the `on_error` hook (and Apprise), I ended up adding a new hook type that triggers an error hook (and Apprise) as necessary. This required refactoring the way that hooks work, both under the hood and at the configuration file level. Documentation is here: https://torsion.org/borgmatic/docs/how-to/add-preparation-and-cleanup-steps-to-backups/ The new hook type is a `configuration` hook, and it runs at the scope of a whole configuration file... in other words, before and after all actions and repositories in that configuration file. Hopefully that works for your use case. This is implemented in main and will be available in the next release.

witten closed this issue

2025-03-12 21:31:08 +00:00

witten referenced this issue from a commit

2025-03-12 21:31:41 +00:00

Claim another implemented ticket in NEWS (#821).

witten commented

2025-04-06 15:45:05 +00:00

Owner

Released in borgmatic 2.0.0!