You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the mission / vision / idea of resticr-robot, it really fit's exactly what i was looking at.
Currently we deploy rclone/restic jobs via chef, run them via cron an report issue via webhooks (mattermost).
While this works, the usual issue is, not getting a notification means:
it's all good and fine (no errors)
or the job simply did not run (out of whatever reasons .. i mean it's corn.)
So on that front, restic-robot seems to be a good pick, esp. with metrics being picked up by prometheus and you can then define alarms if the 'amount of jobs' / 'files' / 'data size' since below a value.
So all in all, i like your concept fairly much!
The final question is, as it is with such projects, roles change, companies change and as it was born it often dies. What is the current health of the project in you POV? Does adopting make sense?
The text was updated successfully, but these errors were encountered:
It's "maintained" by which I mean I'm still alive and able to accept PRs or fix issues, but the software itself is so incredibly simple that there's not a whole lot to go wrong.
One thing to keep in mind would be if Restic changes its command line arguments, since the code just calls the command instead of importing the code (which is written in Go, strange why I made that decision, can't remember why but probably to keep it simple)
I do actually need to employ a backup strategy for a couple of growing projects so I will likely be more active.
Looking at the mission / vision / idea of resticr-robot, it really fit's exactly what i was looking at.
Currently we deploy rclone/restic jobs via chef, run them via cron an report issue via webhooks (mattermost).
While this works, the usual issue is, not getting a notification means:
So on that front, restic-robot seems to be a good pick, esp. with metrics being picked up by prometheus and you can then define alarms if the 'amount of jobs' / 'files' / 'data size' since below a value.
So all in all, i like your concept fairly much!
The final question is, as it is with such projects, roles change, companies change and as it was born it often dies. What is the current health of the project in you POV? Does adopting make sense?
The text was updated successfully, but these errors were encountered: