How did you do that? Did you just teach everyone how to use restic’s cli?
No, we don’t expose restic commands. The idea is that the users will request restore jobs (initially from their CERNBox web interface) which essentially is just adding a restore job in one database. Then, n number of restore agents (restic wrappers) will query this database asynchronously and restore the data directly on their home folder. This is for the “dropbox-like” users, for the pro users our idea is to use restic fuse mount or just create this restore jobs using the command line (but in any case through some kind of wrapper). Exposing directly restic commands would be a bit dangerous as it will give users access to forget, prunning, etc… and we don’t want them to mesh up their backups…
@robvalca How do you deal with credentials? Your clients need some credentials for the repo, your prune workers need some credentials, and the restore workers do too. Did you add multiple keys to each repository, or just share one and the same on all three nodes? I presume however you have different credentials for each repo at least?
Okay… what kind of control do your users get about what is restored? I would imagine that at the very least one should be able to state what file/folder to restore, from what date and probably a target location.
Yep, this is what we use in the prototype.
Yes, the user input will be parsed to the restore’s
--include flag, so a pattern can be used for restoring files/dirs. Also the date of each snapshot will be presented (we store snapshot info after each backup with
restic snapshots --json). The target folder is not configurable, on purpose, and a specific folder with the snapshot timestamp on it will be created under the user’s home (__backup__restore_xXXXX, etc) to avoid overwriting stuff.