Hook "on_warning" #606

New Issue

Closed

opened 2022-10-27 10:59:59 +00:00 by phfn · 8 comments

phfn commented 2022-10-27 10:59:59 +00:00

Copy Link

What I'm trying to do and why

I would like to have a hook (preferebly ntfy) fired, when borg exits with a warning (exit code 1). This would be helpfull, when you try to backup a folder that doas not exist. This could happen when a folder gets moved without your notice.

Other notes / implementation ideas

A config.yaml, after implementing this could look like following:

hooks:
    on_warning:
        - curl -d "Your backups ended with a warning!" ntfy.sh/phfn
        
    ntfy:
        topic: phfn
        
        warn:
            title: Ping!
            message: Your backups ended with a warning!
            
        states:
            - warn

Environment

borgmatic version: [1.7.4]

borgmatic installation method: [pip --user]

Borg version: [1.2.2]

Python version: [3.10.7]

Database version (if applicable): [version here]

operating system and version: [Linux 5.15.74-3-MANJARO]

#### What I'm trying to do and why I would like to have a hook (preferebly ntfy) fired, when borg exits with a warning (exit code 1). This would be helpfull, when you try to backup a folder that doas not exist. This could happen when a folder gets moved without your notice. #### Other notes / implementation ideas A config.yaml, after implementing this could look like following: ```yaml hooks: on_warning: - curl -d "Your backups ended with a warning!" ntfy.sh/phfn ntfy: topic: phfn warn: title: Ping! message: Your backups ended with a warning! states: - warn ``` #### Environment **borgmatic version:** [1.7.4] **borgmatic installation method:** [pip --user] **Borg version:** [1.2.2] **Python version:** [3.10.7] **Database version (if applicable):** [version here] **operating system and version:** [Linux 5.15.74-3-MANJARO]

witten commented 2022-10-27 16:24:45 +00:00

Owner

Copy Link

To clarify, would either the proposed ntfy-specific warn hook or the on_warning command hook meet your needs? Or do you foresee a need for both? Related tickets: #366, #518, #592.

To clarify, would *either* the proposed ntfy-specific `warn` hook or the `on_warning` command hook meet your needs? Or do you foresee a need for both? Related tickets: #366, #518, #592.

phfn commented 2022-10-29 17:19:43 +00:00

Author

Copy Link

Personally i use ntfy, so i only need the 'warn' hook. But i think an 'on_warning' hook would be usefull in other configurations.

Personally i use ntfy, so i only need the 'warn' hook. But i think an 'on_warning' hook would be usefull in other configurations.

phfn commented 2022-10-29 17:22:47 +00:00

Author

Copy Link

If you agree, that this sounds usefull, i could create a patch.

If you agree, that this sounds usefull, i could create a patch.

witten commented 2023-03-27 02:00:25 +00:00

Owner

Copy Link

I apologize for the delay here. I would be totally fine with an ntfy "warn" state being supported; I just don't know how easy it would be to add. That's because right now, borgmatic only differentiates between Borg success and failure. A warn state (exit code one, e.g. files missing) is silently treated as a success. So that would have to change in order for the warn state to be available for plumbing through to the ntfy hook.

Having said that, a PR would be welcome if you're still up to it! I'd be happy to answer questions as you go.

I apologize for the delay here. I would be totally fine with an ntfy "warn" state being supported; I just don't know how easy it would be to add. That's because right now, borgmatic only differentiates between Borg success and failure. A warn state (exit code one, e.g. files missing) is silently treated as a success. So that would have to change in order for the warn state to be available for plumbing through to the ntfy hook. Having said that, a PR would be welcome if you're still up to it! I'd be happy to answer questions as you go.

witten commented 2023-03-27 03:14:46 +00:00

Owner

Copy Link

And here's an alternate idea that may or may not meet your needs: In the next release (1.7.10), there will be a new option in configuration called source_directories_must_exist (implemented in #501), which you can set to true if you'd like borgmatic to check that source directories exist before calling Borg. If they don't exist, borgmatic will error and presumably notify ntfy of the error. (Note that the existence check is not recursive currently.)

And here's an alternate idea that may or may not meet your needs: In the next release (1.7.10), there will be a new option in configuration called `source_directories_must_exist` (implemented in #501), which you can set to `true` if you'd like borgmatic to check that source directories exist before calling Borg. If they don't exist, borgmatic will error and presumably notify ntfy of the error. (Note that the existence check is not recursive currently.)

👍 1

phfn commented 2023-03-31 11:10:39 +00:00

Author

Copy Link

Nice to here from you. source_directories_must_exist is very cool, but stops, i only want to get warned.

Nice to here from you. `source_directories_must_exist` is very cool, but stops, i only want to get warned.

phfn referenced this issue 2023-03-31 11:11:44 +00:00

WIP: Add ntfy warning #664

witten commented 2023-03-31 17:46:08 +00:00

Owner

Copy Link

Here's an alternate idea: The source_directories_must_exist option effectively triggers a pre-check before Borg even runs; borgmatic probes for each source directory existing and errors if any don't. So if the primary thing you're interested in is whether configured source directories exist, what if borgmatic just issued a warning to ntfy whenever they didn't? It could use the same pre-Borg probing mechanism. That might be easier than checking every call to Borg for warning exit codes. The main downside is that it wouldn't handle other Borg warning states.

Here's an alternate idea: The `source_directories_must_exist` option effectively triggers a pre-check before Borg even runs; borgmatic probes for each source directory existing and errors if any don't. So if the primary thing you're interested in is whether configured source directories exist, what if borgmatic just issued a warning to ntfy whenever they didn't? It could use the same pre-Borg probing mechanism. That might be easier than checking every call to Borg for warning exit codes. The main downside is that it wouldn't handle other Borg warning states.

witten added the

waiting for response

label 2023-06-28 18:41:13 +00:00

witten removed the

waiting for response

label 2023-07-03 16:15:47 +00:00

witten commented 2023-07-03 16:16:37 +00:00

Owner

Copy Link

Closing for now in favor of source_directories_must_exist. But we can always reopen and revisit this later.

Closing for now in favor of `source_directories_must_exist`. But we can always reopen and revisit this later.

witten closed this issue 2023-07-03 16:16:37 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels   

bug

  

data loss

  

design finalized

  

good first issue

  

new feature area

  

question / support

  

security

  

waiting for response

No Label

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

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#606

No description provided.