I can understand why it’s unexpected for you as a user. For me as a developer, I need to ask (honest question): How would restic detect that the files which were previously located in /original/path/mydata are the same that are now mounted at /usbdisk/mydata? Sure, we could try matching the file names and sizes and inodes and device IDs, but all that is only approximate and not exact. Therefore, at the moment, we err on the side of caution and always read data that we’re not sure where it comes from. That’s what users can (and should) expect from a backup program: Saving the correct data
We’ve had several reports now with users reporting their surprise and non-understanding of why restic re-reads the files. Do you have any idea on how to improve this situation from a user’s point of view?
Nope, restic will just detect that the top-level directory name is different, and continue as if --parent wasn’t specified at all. That’s the case at least for the current archiver code, it may change when I get around to finishing the new one. I’ll keep it in mind
Well, I don’t have any ideas, and now that I thought about it, there might not be any good solutions indeed. I’m happy as long as deduplication is happening and not all data is re-uploaded. So maybe if I could somehow see the size each snapshot contributes towards the total repo size, and the total repo size up to each snapshot, when executing restic snapshots, much like what’s already discussed in this issue:
ID Date Host Tags Directory Size Total
-----------------------------------------------------------------------------------
abcdefgh 2018-01-13 11:13:54 user /path/mydata 84.2 MB 84.2 MB
ijklmnop 2018-01-14 11:13:54 user /path/mydata 10.1 MB 94.3 MB
qrstuvwx 2018-01-15 11:13:54 user /path/mydata 1.3 MB 95.6 MB
yzabcdef 2018-01-16 11:13:54 user /path/mydata 2.1 MB 97.7 MB
-----------------------------------------------------------------------------------
4 snapshots (97.7 MB)
