borg info and status with separate keys for monitoring
- Dominant language
- Python
- Stars
- 13.7k
- Forks
- 875
- Avg merge
- 11h 15m
- Merged PRs (30d)
- 192
Description
This is a QEUESTION and/or discussion for ENHANCEMENT
Since the concept of borg is genious I use it for multiple off site backups. That said while deploying the it got me thinking and more and more questions pop up around the web on monitoring and alarting. To date I perform manual checks, but obviously that's no long term solution. Therefor I would like to put out some suggestions, which I even would concider to implement, but only if the collective likes the idea in the first place.
- monitoring current backup status
- a "get only status" key, for monitoring purposes
- get a cached version of borg info (for a specific snapshot)
- provide a user selectable redundancy of data
One thing I might mention first:
To keep an uncorrupted chain of files it is required to use a RAIDed FS with checksums on ECC memmory (btrfs, zfs, refs if you really insist).
To do so I would suggest to implement writing a kind of log file of each backup process, which contains (maybe even a user selectable subset of available information) in a JSON file (or whatever, I don't really care). Borg info ::my_abckup_last_month is painfully slow, as it really has to look into the backup. This JSON file may itself be written by the backup process and red by any other borg process, so no exclusive lock. In addition that file would be encrypted with AES (or whatever), but not with the repo key, but more like in a PGP manner:
- A random key is generated by the "owner backup process"
- A file which is also crypted/signed with the repo key contains a list of asymmetric keys, which should only be able to decode the log file
- The backup process encrypts the random key with each public key in list and stores it by the pubKey hash
- It also creates a special entry, which is the random key encrypted with the repo key
-The owner of the according private key can then use his private key to retrieve the symmetric key to decrypt the log file
- Besides reading the log these keys would be worthless
That's the basic idea, from a very top level view. File would also need some kind of status in it, and may not be red the moment it's appended to, but I think one might get the generic idea. Please feel free to correct me, if I made some completely wrong assumptions about borg architecture, as I am just assuming the inner workings of borg from my generic knowledge.
Contributor guide
Assessment
This issue has not been assessed yet.