@epadepat, let me see whether I grasped your use case:
- You have a couple of hosts
H3, … which you want to take backups from. Some of these are in your local network, some are remote but available via Internet.
- You want to backup all of these into the same repo, profiting from the deduplication of data.
- You want to trigger these backups from the machine
S1 into your local network, on which the backup storage lies (what restic calls the repository).
Restic supports 1 and 2 directly. For 2, it doesn’t matter whether shared data lies in different directories on the hosts, it will deduplicate the contents of
H2:/another/place/for/foo all the same, thanks to the content defined chunking (cf. https://restic.readthedocs.io/en/latest/design.html, “Backups and Deduplication”)
Item 3 is not supported directly at the moment, but it’s easy to workaround that. I assume you can reach
H1 etc. via SSH. In that case, run github.com/restic/rest-server on
S1, and create a SSH-tunnel for the HTTP-access (let’s assume
ssh h2 -R 8000:localhost:8000) and use
restic -r rest:http://127.0.0.1:8000 backup /folder/to/foo.
In case you are not worried about HTTP security or a firewall is preventing you from doing so, you could also use an HTTP URL that points to
S1 directly. Also, of course, SSH is just one of many ways to tunnel HTTP.
Last, but not least, in case
H1 et al. can reach
SFTP, you could also use that. Although SFTP is a very slow protocol.
If you really need to have dedicated local repositories on
H2 …, you need to make sure all of them use the same key, otherwise the encryption will differ between all hosts and deduplication will never be possible between the hosts.
You could then sync the individual
data/ subfolders of the local repostories to
S1 (e.g. with
rsync), although I’m not sure whether this will duplicate all of the data packs perfectly. You might want to sync the
snapshots/ as well, and definitely call
restic rebuild-index and
restic check on