We already have the http backend which is readonly and rclone serve restic which acts as a server. I would like to have rest-server as a backend so I can sync an existing restic repo to another rest-server for redundancy.
Interesting idea!
It would be possible to get the http backend to understand the restic backends directory listings (which are in JSON form).
Would this actually work though? If you synced a restic server to another restic server would the backup still work?
Also is this something restic can do?
I guess so but I'm mainly interested in PUT/POST/DELETE (well actually POST is not really relevant for restic but PUT and optionally DELETE are). I'm not sure if adding write functionality to the http backend would be in scope.
I am fairly certain it would, restic is pretty agnostic on where/how to transfer and store the repo as long as it resembles a basic directionary structure. Using the rest-server instead of another transfer like SFTP has restic-specific benefits like the append-only feature ensuring no data can be deleted/overwritten, quota tracking via prometheus and integrity checking that the uploaded blocks hashes actually match the filenames.
I don't think restic can do this. My use-case is that I want to have several restic servers that sync their new data to each other for increased redundancy (3-2-1 rule) and convenience (being able to do a backup very fast to a local server which then transfers to an off-site server). I looked into different options to do this (rsync --ignore-existing, rclone --ignore-existing) but just using rest-server seems to be the easiest as it already includes all restic-specific features.
What do you think?
I think it is definitely possible.
Whether it is worth doing or not I don't know - this seems like quite a niche feature. Though having a backend to match rclone serve restic has a certainly pleasing symmetry!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.