Create a cockpit for borgmatic #126
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#126
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,
for me the critical point regarding my backup strategy is, that
it needs to be fully automated
I need to be informed if anything goes wrong
I need to be able to check the current status easily
is fulfilled by borgmatic
explicitly does not mean, that I am not informed for every successful run. This is because one does not notice if one message is missing.
This is currently done for me by getting the crontab output. For this it is important not to get any output in case everything is fine. It works, but I would prefer this to not be dependand on crontab but built into borgmatic
is yet missing. I am spoiled by crashplan:
![Crashplan](https://i1.wp.com/www.accuratereviews.com/wordpress/wp-content/uploads/2015/09/crashplan.jpg)
But I do not request a GUI here... It can all be commandline output
I looked at the borg documentation of available json and I suggest this structure:
during create:
Stats - appears once per repository:
Related issues:
witten/borgmatic#53
witten/borgmatic#86
Regards,
Hendrik
It would require a gui or a web application no?
Hello,
I am just showing an example in the screenshot above.
It could be just a text-output. No User-Interaction and nothing graphical.
Greetings,
Hendrik
It could feasibly be implemented with some logging and a separate command that just parses that log.
Some related discussion on #174.
Hey, moving over from witten/borgmatic#174, I am interested in number 2 of this issue.
I've seen netdata's alerts handler (it is a monitoring tool primarily) and it has a shiittload of them: https://github.com/netdata/netdata/blob/master/health/notifications/alarm-notify.sh.in. If borgmatic implements one handler, someone will come and ask for another.
What is acceptable for borgmatic (not feature creep) and works for us.
I think my feeling is to provide more context to
on_error
(see witten/borgmatic#174). The basic requirements are to know which archive was being backed up and at what time when the failure happened and then to have this available to pass to some handler (pushbullet, twilio, etc.).However, there is a niggling feeling that this is simply a documentation issue and this could be declared out of scope for the tool ... thoughts!?
Some thoughts on this:
Thoughts/reactions?
One thing that would be helpful is: When do y'all intend to use / look at the cockpit output? On every backup? Only when things go wrong, you get alerted, and you need to dig in? Or some other time?
Hello,
yes, clearly option 2 is safer, but it also means 'starting from scratch'...
On the 'when': The notifications should clearly follow a 'lights out philosophy'. No message means, everything is good. If one gets flooded by daily status mails, one will start ignoring them.
This requires of course, that the system runs reilably.
So, maybe a watchdog (did borgmatic actually do something?) would be good. Otherwise, the lights out philosophy can go very wrong.
Greetings,
Hendrik
Yup, that philosophy makes sense to me.
FYI, I reopened and implemented #174 with the idea that it carves off a piece of the ask in this ticket (#126): More immediate alerting when a backup fails.
Still to do: Separate monitoring + cockpit.
Note that #86 is now implemented. That feature supports one approach to the "separate monitoring" ask, which is why I'm mentioning it here.
Okay, I implemented #223 (dead man's switch via Healthchecks integration), and I also wrote up docs on a number of options for borgmatic monitoring and alerting. Feedback is welcome, tickets on new variants of monitoring/alerting are welcome, but I'm going to consider the "separate monitoring" ask in this ticket to be done for now.
Still to do: Cockpit.
Great!
I will try. Thanks!
Hello,
I really like the healthchecks.io integration! Thank you!
Greetings,
Hendrik
just wanted to say that Witten looks like awesome to work with/to hire
Hah, thanks for the kind words. Let me know if you (or your employer) have any projects that need doing!
Given the lack of activity on this ticket (my fault) and the various ways to monitor borgmatic now, I'm closing this ticket. Not all of the features in the original issue are covered by those. But, for instance, Healthchecks or Borgbase UIs go pretty far at proving a borgmatic "cockpit." And Healthchecks can be self-hosted if you don't want to use a third-party cloud provider.
If there are remaining asks unfulfilled that folks still care about, please feel free to file those as separate tickets. Thank you!