Every time I’m about to start using it seriously (beyond tests) I get sidetracked with something that I’m having trouble figuring it out alone, so I came here for help: how is the file hierarchy of the repo’s content (my actual files, I mean; not the restic internal layout of encrypted blobs) related to the file hierarchy of the hosts that send the files to it?
When I do a restic -r url snapshots I see a “Paths” column that shows the original location of my files when I backed them up. That makes me wonder what will happen when I back up the SAME file/folder but from a different mount point. Or what will happen if I back up a DIFFERENT file with the SAME path (e.g. using the /mnt temporary mount point for different drives).
I’ve read the docs and this forum and I was unable to answer those questions, which makes me think that I have to “plan harder” how to structure my backups and how many repositories to make. But the lack of info regarding this may be because I’m missing something trivial and that’s why I’m asking your help.
That makes me wonder what will happen when I back up the SAME file/folder but from a different mount point.
You would get a new snapshot saved to the repository, with the different mount point listed as the path. It will by default be grouped separately by restic forget as a result of this.
As an aside, it is worth noting that the first time you snapshot this new mount point restic will re-read and re-chunk all of the files. This is because it cannot find a “parent” snapshot for the mount point; while the data is the same, the path to the data has changed.
However, restic will not send any duplicate data to the repository, so the repository will not increase in size (apart from the very small size of the snapshot metadata). Any subsequent runs using the new mount point will be just as fast as using the old mount point, as they can use the snapshot you just took as a parent.
Or what will happen if I back up a DIFFERENT file with the SAME path (e.g. using the /mnt temporary mount point for different drives).
The backup path would still show as /mnt when listed via restic snapshots, but the content of the snapshot would reflect the state of /mnt at the point when the snapshot was taken.
If you want to specifically snapshot, say /mnt/driveA and /mnt/driveB, and treat snapshots of each separately in terms of retention (i.e. grouping by restic forget), it might be simpler to explicitly back-up their individual mount points, rather than just backing up /mnt as a whole.
If that doesn’t work for your use case, you could also use tags to identify which snapshots of /mnt contain which drives.
You would get a new snapshot saved to the repository, with the different mount point listed as the path. It will by default be grouped separately by restic forget as a result of this.
You made me realize that my example is essentially equivalent to backing up a directory in which two copies of a file live in two different subdirs. It may mean something to the user, so it’s desirable they get treated as two different objects (albeit dedup).
Going back to my example, it’s my responsibility to use the same mount point for an external drive every time I want to back it up if I don’t want them to be messed up. I suspect that if I do a restore from the last snapshot, I would get the last one. I still don’t fully understand if when one does a restore exists the notion of a full file hierarchy stemming from / that collapses all snapshots (like Union mount) or one always is limited to pull from specific snapshots and has to manually rebuild the original layout of the source filesystems.
I suspect my uneasiness comes from never having to make a “restore” so I have zero experience “repopulating” a drive, a partition, etc. I still don’t imagine how I should organize a restic repo (how to manage paths) and even when to use two separate repos (one for each drive? for each partition? one for each Linux install?).