Feature request for on_backup_error #270
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#270
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
Hello!
Currently the
on_error
hook also runs when something goes wrong with a restore, i.e.:Will fail if
/root/restoretest
does not yet exist with the following error:The fact that
/root/restoretest
does not yet exist is my fault of course; I should create it first. But I would rather not have theon_error
hook trigger because of it; because it sends a message to nagios that something went wrong with the backup creation. I only mean to do this for when we create backups, prune backups or check them. Not for restore tasks.Is it possible to filter this?
Thank you!
Niels
There have been a couple of other tickets recently about making hooks more granular / per-action, so this fits right in with that. I'll have to think about the migration path (if any) for the existing
on_error
hook if we addon_backup_error
that just fires on creates, for instance.Another option would be to support filtering of error triggering when an interactive command is run like
extract
. See witten/borgmatic#249 for more discussion on this approach.Side note: I'd support a more formal Nagios integration with borgmatic if that'd be useful.
Cheers,
If there are already different discussions feel free to close this one :)
Another option would be having (environment) variables that we can expose to the on_error script (i.e. as a parameter to the script) that I could use within the on_error script itself to determine what action it has to take. That parameter could include something like the type of tasks (backup, prune, etc), optional err. msg, etc...
Formal Nagios integration would be great but perhaps would be tricky to implement since people have different use-cases?
For us, after the backup is done we parse a list with the "borgmatic list" output, parse for successful backups and report the most recent backup name/date to the monitoring system through its API.
For us specifically we use Icinga and not Nagios, and the reporting is done as a passive Icinga check.
I'll leave this open to make sure I address the need, even if the same solution ends up satisfying multiple tickets. Point taken about the parameter to the script.. That could certainly work.
Understood about Nagios/Icinga. Feel free to file tickets if anything in borgmatic could make that monitoring integration easier.
This is released now in borgmatic 1.4.21. I went with the approach of simply restricting the
on_error
hook to trigger only forprune
,create
, andcheck
actions. Please let me know how it works out for you.