Restore ability to run post-backup commands only on success #1066

Closed
opened 2025-04-11 12:57:51 +00:00 by sanderkoenders · 8 comments

What I'd like to do and why

In versions prior to 2.0.0, I relied on the after_actions hook to run a script only when Borgmatic completed successfully. This behavior changed in version 2.0.0, where the hook now runs regardless of whether the actions succeeded or failed. I would like to restore the ability to run a command only when Borgmatic finishes without errors. This is useful for post-backup tasks that should not run if the backup process fails.

Other notes / implementation ideas

One possible solution is to introduce a new command, such as after: success, which executes only when Borgmatic runs successfully. This would complement the existing after: error command and give users finer control over post-run actions depending on the outcome. This addition would restore a useful behavior that existed in earlier versions and improve the flexibility of Borgmatic's command system.

### What I'd like to do and why In versions prior to 2.0.0, I relied on the after_actions hook to run a script only when Borgmatic completed successfully. This behavior changed in version 2.0.0, where the hook now runs regardless of whether the actions succeeded or failed. I would like to restore the ability to run a command only when Borgmatic finishes without errors. This is useful for post-backup tasks that should not run if the backup process fails. ### Other notes / implementation ideas One possible solution is to introduce a new command, such as `after: success`, which executes only when Borgmatic runs successfully. This would complement the existing `after: error` command and give users finer control over post-run actions depending on the outcome. This addition would restore a useful behavior that existed in earlier versions and improve the flexibility of Borgmatic's command system.
sanderkoenders changed title from Add a after success command for scripts that should only be executed after success to Restore Ability to Run Post-Backup commands Only on Success 2025-04-11 13:06:11 +00:00
sanderkoenders changed title from Restore Ability to Run Post-Backup commands Only on Success to Restore ability to run post-backup commands only on success 2025-04-11 13:06:29 +00:00
Owner

Thanks for filing this.. It seems like a reasonable request to me. One difficulty with after: success though is that you wouldn't be able to give it a particular scope like action, repository, configuration, or everything. Success can sometimes be relative. You might not want the successful completion of backing up one repository or configuration file to affect the "success" state for another. So can you say a little more about what kind of success actions you're taking? What exactly are they doing? Are they related to a particular repository or configuration file, or would you always want them to run as late as possible in borgmatic's execution, like the everything hook does today?

Anyway, if we're to take the scope into account, I would propose something like this to meet your needs:

commands:
    - after: action  # Or "repository", "configuration", etc.
      when: [create]
      states: [finish]
      run:
          - post-backup-success.sh

I'm open to other ideas as well. Let me know your thoughts.

EDIT: Updated the new option name/value slightly.

Thanks for filing this.. It seems like a reasonable request to me. One difficulty with `after: success` though is that you wouldn't be able to give it a particular scope like `action`, `repository`, `configuration`, or `everything`. Success can sometimes be relative. You might not want the successful completion of backing up one repository or configuration file to affect the "success" state for another. So can you say a little more about what kind of success actions you're taking? What exactly are they doing? Are they related to a particular repository or configuration file, or would you always want them to run as late as possible in borgmatic's execution, like the `everything` hook does today? Anyway, if we're to take the scope into account, I would propose something like this to meet your needs: ```yaml commands: - after: action # Or "repository", "configuration", etc. when: [create] states: [finish] run: - post-backup-success.sh ``` I'm open to other ideas as well. Let me know your thoughts. EDIT: Updated the new option name/value slightly.
Author

I was using the command functionality to send notifications through Gotify. While I'm aware of Apprise, it unfortunately doesn't meet my needs for two key reasons.

First, similar to the built-in commands, Apprise sends a notification at the end of a backup regardless of whether it completed successfully or encountered errors. This limits its usefulness for monitoring purposes.

Second, Apprise doesn't allow assigning different priorities to different types of messages. Ideally, I would like to send routine notices (such as "backup started" or "backup completed successfully") with priority 2, and reserve priority 8 for error messages that require immediate attention.

Because of these limitations, I’ve been using the following commands instead:

commands:
  - before: everything
    run:
      - |
        curl "https://$GOTIFY_URL/message?token=$GOTIFY_TOKEN" \
          -F "title=Borg backup to Hetzner initiated" \
          -F "message=Backup to Hetzner initiated at $(date)" \
          -F "priority=2" > /dev/null 2>&1
  - after: error
    run:
      - |
        curl "https://$GOTIFY_URL/message?token=$GOTIFY_TOKEN" \
          -F "title=Borg backup to Hetzner failed" \
          -F "message=Backup to Hetzner failed at $(date)" \
          -F "priority=8" > /dev/null 2>&1
  - after: repository
    run:
      - |
        curl "https://$GOTIFY_URL/message?token=$GOTIFY_TOKEN" \
          -F "title=Borg backup to Hetzner finished" \
          -F "message=Backup to Hetzner finished at $(date)" \
          -F "priority=2" > /dev/null 2>&1

In previous versions, prior to 2.0.0 after: reposiitory would only send the notification when no error had occurred. Now it sends the notification regardless.

Coming back to your suggestion. I think it fits my needs flawlessly. Ideally I would like to send the notification after: everything but I think it makes sense to implement the suggested functionality for any scope like action, repository, configuration or everything.

I was using the command functionality to send notifications through Gotify. While I'm aware of Apprise, it unfortunately doesn't meet my needs for two key reasons. First, similar to the built-in commands, Apprise sends a notification at the end of a backup regardless of whether it completed successfully or encountered errors. This limits its usefulness for monitoring purposes. Second, Apprise doesn't allow assigning different priorities to different types of messages. Ideally, I would like to send routine notices (such as "backup started" or "backup completed successfully") with priority 2, and reserve priority 8 for error messages that require immediate attention. Because of these limitations, I’ve been using the following commands instead: ```yaml commands: - before: everything run: - | curl "https://$GOTIFY_URL/message?token=$GOTIFY_TOKEN" \ -F "title=Borg backup to Hetzner initiated" \ -F "message=Backup to Hetzner initiated at $(date)" \ -F "priority=2" > /dev/null 2>&1 - after: error run: - | curl "https://$GOTIFY_URL/message?token=$GOTIFY_TOKEN" \ -F "title=Borg backup to Hetzner failed" \ -F "message=Backup to Hetzner failed at $(date)" \ -F "priority=8" > /dev/null 2>&1 - after: repository run: - | curl "https://$GOTIFY_URL/message?token=$GOTIFY_TOKEN" \ -F "title=Borg backup to Hetzner finished" \ -F "message=Backup to Hetzner finished at $(date)" \ -F "priority=2" > /dev/null 2>&1 ``` In previous versions, prior to 2.0.0 `after: reposiitory` would only send the notification when no error had occurred. Now it sends the notification regardless. Coming back to your suggestion. I think it fits my needs flawlessly. Ideally I would like to send the notification `after: everything` but I think it makes sense to implement the suggested functionality for any scope like `action`, `repository`, `configuration` or `everything`.
Owner

Thanks for the details on your setup! I'm glad to hear the proposed config might work for your use case.

First, similar to the built-in commands, Apprise sends a notification at the end of a backup regardless of whether it completed successfully or encountered errors. This limits its usefulness for monitoring purposes.

Side note: I think this is actually a bug, fixed in #1065 and part of the next borgmatic release.

Second, Apprise doesn't allow assigning different priorities to different types of messages. Ideally, I would like to send routine notices (such as "backup started" or "backup completed successfully") with priority 2, and reserve priority 8 for error messages that require immediate attention.

Ah, yeah, I see that. In theory that could be added, but it would likely require putting Gotify-specific code into the "generic" borgmatic Apprise hook. Which makes me wonder: Maybe it's time for borgmatic to get a native Gotify hook to support this kind of functionality? There's already one for ntfy, for instance.

Thanks for the details on your setup! I'm glad to hear the proposed config might work for your use case. > First, similar to the built-in commands, Apprise sends a notification at the end of a backup regardless of whether it completed successfully or encountered errors. This limits its usefulness for monitoring purposes. Side note: I think this is actually a bug, fixed in #1065 and part of the next borgmatic release. > Second, Apprise doesn't allow assigning different priorities to different types of messages. Ideally, I would like to send routine notices (such as "backup started" or "backup completed successfully") with priority 2, and reserve priority 8 for error messages that require immediate attention. Ah, yeah, I see that. In theory that could be added, but it would likely require putting Gotify-specific code into the "generic" borgmatic Apprise hook. Which makes me wonder: Maybe it's time for borgmatic to get a native Gotify hook to support this kind of functionality? There's already one for ntfy, for instance.
Author

Having a dedicated gotify integration with priorities would be awesome. That would also allow the logs to be send along with the notification where my "primitive" solution with commands does not support it.

Having a dedicated gotify integration with priorities would be awesome. That would also allow the logs to be send along with the notification where my "primitive" solution with commands does not support it.
Owner

Sounds good! I'll look into what that would take when I get a chance. I'm actually a Gotify user myself, so I can see the utility.

Sounds good! I'll look into what that would take when I get a chance. I'm actually a Gotify user myself, so I can see the utility.
Owner

I went ahead and implemented the original ask in this ticket with a new states: option for after command hooks. So states: [finish] will make the hook only trigger on success. This is in main and will be part of the next release! And docs will be online here shortly: https://torsion.org/borgmatic/docs/how-to/add-preparation-and-cleanup-steps-to-backups/

For the Gotify hook part, I broke that off into a separate ticket: #1070. Please feel free to follow along there.

I went ahead and implemented the original ask in this ticket with a new `states:` option for `after` command hooks. So `states: [finish]` will make the hook only trigger on success. This is in main and will be part of the next release! And docs will be online here shortly: https://torsion.org/borgmatic/docs/how-to/add-preparation-and-cleanup-steps-to-backups/ For the Gotify hook part, I broke that off into a separate ticket: #1070. Please feel free to follow along there.
Author

Thanks so much for the effort and the speed at which this feature request was fulfilled. I am looking forward to the Gotify implementation as well but until then I am more than happy that this feature request was implemented.

Thanks so much for the effort and the speed at which this feature request was fulfilled. I am looking forward to the Gotify implementation as well but until then I am more than happy that this feature request was implemented.
Owner

Released in borgmatic 2.0.3!

Released in borgmatic 2.0.3!
Sign in to join this conversation.
No milestone
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
borgmatic-collective/borgmatic#1066
No description provided.