There is one thing that I am unsure and that I could not find input on the forum and documentation.
In restic, I create a new repository then can start backuping files.
If I need to backup 2 separate directory (/home/ and /Photos/), I can do so within that same resporitory.
However, this make all other operations longer : snapshots, prune, restore, ls now always needs --path or --tag to do the job correctly.
I have not read how deduplication works, but it may try to match stuff from photos to home, which is not useful.
What if instead I created different repository for each path to backup ? With file backend it does not looks like that much work.
In the end I plan on testing it with minio so it would incur some. I don’t know if I want to create multiple repo.
but back to the question : 1 repo with ~6-8 different backup path and different backup schedules, backup prune (which will be harder to read) or multiple repositories ? What’s the advantage of using only one repo ? Multi-host ?
Hm, are you sure that’s the case? Sure, the output of snapshots will be longer (there are more snapshots after all), but prune automatically builds groups of snapshots and applies the policy to each group separately, so you don’t need to handle the paths differently (try with --dry-run to see the effect). If you want to have different retention policies, working with tags is probably the easiest way. restore and ls take a snapshot ID, so that’s the same.
I can’t see a large difference here, except when you want to have different retention policies.
You’re right, you won’t benefit from the deduplication here. It won’t be harmful either, though.
There’s no difference, you can use restic either way. Try it, and report back what your experiences are
thank you for the answer I had replied through mail but the day after I received a notification that it did not work.
I am going to add multiple path in the same repo. I guess I could create 1 repo for each people as this allow to control the maximum size to be backuped, but I am no there yet.
So far I can see that backuping to a local folder will create 5 times less files and be a little bit faster than backuping to minio that point to the same disk. I need to continue test it by basically… using it for real and see what happen. I see that there is no compression, but I can understand behind the lines that at this point in time, disk are big, space is cheap and in my case I don’t have a lot of “compressible” data so I am no bothered by that.
How does prune do that? I thought only forget does this.
Doesn’t prune need to check against all snapshots to be sure that a blob is no longer needed? There’s also a rebuild of index involved in prune, doesn’t that also slow down the process?
If I had
a small, frequently updated/backed up/pruned folder, and
a large, infrequently updated/backed up/pruned folder.
Wouldn’t putting them in the same repository slow down some operations (check and prune in particular) that only needs to be done on the smaller folder?