Absolute newbie here.
Question: is it practical to use restic to mount a remote s3 repo, make (limited) changes to files via standard filesystem commands, and then get a snapshot of the (changed) mounted repo without having to at any point re-download the full content or a significant portion thereof? Given an average repo size of about 100mb, with perhaps 15k files each? Are there any restic-specific performance and reliability issues beyond network speed and storage space?
Does this even make sense? It would be very handy for me if it did…
mounted repo is read only. Its only purpose is to look around and/or restore some content. That’s it.
Okay. Thanks!
I’m backing up (and periodically restoring) several remote machines with my own app. Currently it stores each file in s3, and tracks/applies incremental changes via a db and s/ftp/s.
It’s distributed, so can do this very quickly in most scenarios, depending on capability of the targeted machine’s network & so on. It would be very nice to be able to use restic’s deduplication and other features, though. I suppose I could store each incremental changeset in its own repo, then pull/apply the changes myself since my app already tracks the storage location of each version of each file. I was hoping for something cleaner. Also, the deduplication would be severely limited in that scenario.
Is there a way to add a new folder to an existing repo and have restic ignore all other content, such that a new changeset could take advantage of the deduplication without my backup devices needing to download the full set of source files? Would ignores work in this way?
The point of the “new folder” is just to use deduplication, not to use restic itself for backups and restores. Some of the machines running my app don’t have a lot of capacity, but they can still help with the “one file at a time” approach.
extracting the above as a new question