on_error hook needs corresponding on_success hook #475

New Issue

Closed

opened 2021-12-06 13:32:28 +00:00 by DonRichie · 5 comments

DonRichie commented 2021-12-06 13:32:28 +00:00

Copy Link

Problem

I am currently using an selfhosted instance of healthchecks.io to monitor my backups.
The "everything" check fails, but is displayed as succeeded.

Why it is happening

You can see a picture like this for the check receiving pre_everything, post_everything and failure hooks.

The following is happening:

1. The pre_everything hook correctly signals the start of the borgmatic execution.
2. After that a failure happens and the fail hook is called (borg lock taken in this case).
3. But now immediately after it the post_everything hook is called signaling a success.

The result is that the failed backup is marked as success. This is a completely expected behaviour since the post_everything hook is supposted to be called in any case. But it doesn't fit to my use case.

Proposed solution

Please add an on_success hook corresponding to the on_error hook to enable users to correctly distinguish between succeeded and failed backups.

### Problem I am currently using an selfhosted instance of healthchecks.io to monitor my backups. The "everything" check fails, but is displayed as succeeded. ### Why it is happening You can see a picture like this for the check receiving pre_everything, post_everything and failure hooks.  **The following is happening:** 1. The pre_everything hook correctly signals the start of the borgmatic execution. 2. After that a failure happens and the fail hook is called (borg lock taken in this case). 3. But now immediately after it the post_everything hook is called signaling a success. The result is that the failed backup is marked as success. This is a completely expected behaviour since the post_everything hook is supposted to be called in any case. But it doesn't fit to my use case. ### Proposed solution Please add an on_success hook corresponding to the on_error hook to enable users to correctly distinguish between succeeded and failed backups.

witten commented 2021-12-06 19:02:52 +00:00

Owner

Copy Link

Thanks for bringing this to my attention. Two thoughts:

1. The existing after_backup hook is basically the "success" hook for create actions. It's triggered when the backup has completed successfully. However...
2. Is a reason you're not able to use the built-in borgmatic Healthchecks hook to talk to your self-hosted Healthchecks server instead of the pre_everything and post_everything hooks? The built-in Healthchecks integration should handle all of your use cases for transmitting successes and failures. And if it's not, it should probably be fixed!

Thanks for bringing this to my attention. Two thoughts: 1. The existing `after_backup` hook is basically the "success" hook for `create` actions. It's triggered when the backup has completed successfully. However... 2. Is a reason you're not able to use the [built-in borgmatic Healthchecks hook](https://torsion.org/borgmatic/docs/how-to/monitor-your-backups/#healthchecks-hook) to talk to your self-hosted Healthchecks server instead of the `pre_everything` and `post_everything` hooks? The built-in Healthchecks integration *should* handle all of your use cases for transmitting successes and failures. And if it's not, it should probably be fixed!

DonRichie commented 2021-12-07 03:56:37 +00:00

Author

Copy Link

My specific use case is that I wanted to find out how much time the subtastsks backup, check and create take.
Therefore I created 4 separate healthchecks and linked them to before_, after_, pre_everything and post_everything. The on_error hook is sent to the everything check.

Using the healthchecks integration should only give me the total time of the whole borgmatic run as I understood it.

By the way my favourite solution would be having a hook for statistics. Sending some measured durations as json string via http POST. That would require templating for the http-body, but enable me to send my statistics directly to influxdb for example.

My specific use case is that I wanted to find out how much time the subtastsks backup, check and create take. Therefore I created 4 separate healthchecks and linked them to before_*, after_*, pre_everything and post_everything. The on_error hook is sent to the everything check. Using the healthchecks integration should only give me the total time of the whole borgmatic run as I understood it. By the way my favourite solution would be having a hook for statistics. Sending some measured durations as json string via http POST. That would require templating for the http-body, but enable me to send my statistics directly to influxdb for example.

timvahlbrock commented 2021-12-08 10:08:22 +00:00

Copy Link

What about covering this with #473?

What about covering this with #473?

witten commented 2022-05-24 21:29:52 +00:00

Owner

Copy Link

I apologize for the delay in getting back to this. I think I'm missing something though. "backup" and "create" are really the same thing as far as borgmatic is concerned. For that, you should be able to use the before_backup/after_backup hooks. And for check, the before_check/after_check hooks should work. Similar thing if you want to time any of the other actions. That means you might not need to use the everything hooks?

I agree that a statistic hook would be pretty cool.

I apologize for the delay in getting back to this. I think I'm missing something though. "backup" and "create" are really the same thing as far as borgmatic is concerned. For that, you should be able to use the `before_backup`/`after_backup` hooks. And for check, the `before_check`/`after_check` hooks should work. Similar thing if you want to time any of the other actions. That means you might not need to use the everything hooks? I agree that a statistic hook would be pretty cool.

witten added the

waiting for response

label 2022-05-24 21:29:58 +00:00

witten commented 2022-10-05 06:12:52 +00:00

Owner

Copy Link

Closing this for now, but feel free to follow up. We can always reopen it. Thanks!

Closing this for now, but feel free to follow up. We can always reopen it. Thanks!

witten closed this issue 2022-10-05 06:12:52 +00:00

witten removed the

waiting for response

label 2022-10-05 06:13:02 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

spot-check

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

3 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#475

No description provided.