Command to check age of last successfull backup #941

New issue

Closed

opened 2024-11-18 13:20:58 +00:00 by RubenMakandra · 2 comments

RubenMakandra commented

2024-11-18 13:20:58 +00:00

What I'd like to do and why

Hi,
I would like to have a command in borgmatic which compares the age with of the last successful backup with a given (warn and critical) duration, and returns appropriate exist codes and/or messages depending on the actual age of the backup.
Ideally with some option to customize return values, e.g. return values nagios/icinga could parse.
This would make backup monitoring easier for us, since our current approach consists of a wrapper around borgmatic, which compares the output of list with the given time values.

Is this feature something you would consider in scope for borgmatic?
We would be interested to contribute a pull request for this.

Other notes / implementation ideas

No response

### What I'd like to do and why Hi, I would like to have a command in borgmatic which compares the age with of the last successful backup with a given (warn and critical) duration, and returns appropriate exist codes and/or messages depending on the actual age of the backup. Ideally with some option to customize return values, e.g. return values nagios/icinga could parse. This would make backup monitoring easier for us, since our current approach consists of a [wrapper]([url](https://github.com/makandra/check_borgmatic)) around borgmatic, which compares the output of `list` with the given time values. Is this feature something you would consider in scope for borgmatic? We would be interested to contribute a pull request for this. ### Other notes / implementation ideas _No response_

witten commented

2024-11-19 20:21:16 +00:00

Owner

So what's the alternative? Well, borgmatic does have plenty of monitoring code that's specific to a third-party product or service, but it's relegated to separate hooks that are triggered transparently from the existing standard borgmatic actions.

But that's not a silver bullet either. The mismatch with using a solution like hooks for your ask is that the existing monitoring "hooks" are all oriented around hitting remote monitoring APIs when backups start, finish, or fail. None of them right now influence borgmatic's exit code, although in theory that might be possible. They do all have hook-specific configuration, which might be a great place to support configuration of warn/critical durations and even exit codes.

Another challenge is that these hooks all fire on the create action, which isn't what you want at all. Getting back to your initial custom action idea, you'd need a monitoring hook to somehow kick in on, presumably, a new action that's specific to monitoring. Say, borgmatic monitor or similar. That could then trigger some hook-specific code if that hook is configured.

Just to be clear, the way that I'm riffing on your initial idea here is that instead of making a new action that does it all, I'm suggesting making a new action that delegates to a hook specific to code for your use case. Call it the Nagios/Icinga hook, I don't know.

It's also worth asking: Are the other ways to integrate with Nagios/Icinga, e.g. an approach more like one of the existing monitoring hooks? Or is the exit code approach just the most convenient?

Anyway, this is just my initial reaction. I'm not dead set on any particular approach.

Tangentially related: #617.

Thanks for filing this. Here's the dilemma with this feature: I totally understand the need here, but adding a whole new action just for this one use case seems a little ... specialized? It's almost like it'd be the `borgmatic nagios` action even if it wasn't called that. And I realize it wouldn't have to do anything Nagios/Icinga specific, but the consumption of this feature would be specific to that use case, especially once you factor in the custom exit codes. So what's the alternative? Well, borgmatic _does_ have plenty of [monitoring code that's specific to a third-party product or service](https://torsion.org/borgmatic/docs/how-to/monitor-your-backups/#third-party-monitoring-services), but it's relegated to separate hooks that are triggered transparently from the existing standard borgmatic actions. But that's not a silver bullet either. The mismatch with using a solution like hooks for your ask is that the existing monitoring "hooks" are all oriented around hitting remote monitoring APIs when backups start, finish, or fail. None of them right now influence borgmatic's exit code, although in theory that might be possible. They do all have hook-specific configuration, which might be a great place to support configuration of warn/critical durations and even exit codes. Another challenge is that these hooks all fire on the `create` action, which isn't what you want at all. Getting back to your initial custom action idea, you'd need a monitoring hook to somehow kick in on, presumably, a new action that's specific to monitoring. Say, `borgmatic monitor` or similar. That could then trigger some hook-specific code if that hook is configured. Just to be clear, the way that I'm riffing on your initial idea here is that instead of making a new action that does it all, I'm suggesting making a new action that delegates to a hook specific to code for your use case. Call it the Nagios/Icinga hook, I don't know. It's also worth asking: Are the other ways to integrate with Nagios/Icinga, e.g. an approach more like one of the existing monitoring hooks? Or is the exit code approach just the most convenient? Anyway, this is just my initial reaction. I'm not dead set on any particular approach. Tangentially related: #617.

witten added the

new feature area

label

2024-11-19 20:21:22 +00:00

RubenMakandra commented

2024-11-22 07:12:03 +00:00

Author

Thanks for taking the time to write this comprehensive response.
I understand your reluctance to add new code which indeed has a pretty narrow use case. We will evaluate some alternative solution we could choose, and take a closer look at the existing hooks.
Closing this for now, if we cannot make one of the other options work I will come back to it later.

Thanks for taking the time to write this comprehensive response. I understand your reluctance to add new code which indeed has a pretty narrow use case. We will evaluate some alternative solution we could choose, and take a closer look at the existing hooks. Closing this for now, if we cannot make one of the other options work I will come back to it later.

👍 1

RubenMakandra closed this issue

2024-11-22 07:12:03 +00:00