Feature Request: Store backup results to a JSON file #617
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
What I'm trying to do and why
Monitoring backups is essential and the only way to provide information to a monitoring system is to use hooks. Traps are not reliable, storing to a file is perhaps the better idea. But the status is not enough, to monitor the backups more informations will be useful.
Example JSON file
This can be done by using hooks and a provided python script, i.e.
write-status
Other notes / implementation ideas
It would be more elegant to have this feature integrated and extended providing more information about the backup. The integration could be done by providing relevant information as variable, i.e. defining the max_age inside the borgmatic configuration and to be used like {configuration_filename}. Additional information like transferred data to the backup repository would be also nice to see in the status. But this information is only forwarded from borg through borgmatic. Maybe it's possible to send all forwarded logs through a couple of regex and fetch data and store it also to variables.
Log Example
borgmatic: INFO RemoteRepository: 366.38 MB bytes sent, 32.64 kB bytes received, 215 messages sent
Maybe to fetch the data like that and store this to variables as well.
That's an interesting idea about parsing the Borg output for basic backup statistics. The currently supported way to monitor the status and duration of borgmatic backups is to use one of the supported third-party monitoring services, some of which you can host yourself if you prefer. I assume none of those will work for your use case or you're already settled on a different tool? And/or perhaps you need the additional stats like bytes sent/received, etc?
Could you talk about how you intend to consume this JSON file? And what actions (if any) do you intend to take when this downstream tool consumes the JSON? Thanks!
I consume the file with Zabbix, just monitoring this file and discover it. The big advantage is i don't have to do to much configuration in zabbix in case of iterating this file and creating the monitored items in an automated way. As soon i create a new backup job a new JSON entry will be created and detected by Zabbix. And i don't need additional tools and be able to integrate borgmatic into the central monitoring solution.
Zabbix template
Thanks for providing the additional detail, and I apologize for the delay in getting back to this. Here would be my recommendation for anyone looking to integrate a feature like this with borgmatic:
borgmatic create
results other than success/failure, so some data gathering may need to be added in order to support some of the requested JSON fields. It's possible that an initial version could start simple with only a few fields, and then additional fields could be added over time as needed.Related ticket: #385.
I can take this, it might make it easier for me to test monitoring hooks too.
Should I also add additional data gathered from the output of the
create
command to other monitoring hooks?If it makes sense, sure. Not all of the monitoring hooks have anywhere to slot in that data in a structured way though. I'd also be fine just starting with this proposed hook and worrying about the other monitoring hooks later.
Since this ticket was created, a Zabbix monitoring hook has been added to borgmatic. However it's mostly just sending start/finish/fail information, which implicitly satisfies some of the asks here but not all of them. So my question is if:
Thanks a lot to integrate a Zabbix hook. The only information which might be useful is to provide metadata of the backup, i.e. how much data are transferred. The JSON file is just a workaround. The most flexible method could be sending different values to specific item ID's. In the best case also manual defined values. The reason behind is the monitoring if a backup should run but it didn't run or stopped before the status were pushed to Zabbix. If we expect to run a backup once a week an alert has to be triggered if the last backup was done 8 days before. This was the reason i used the max-age parameter individually with every backup job.