I would like to know whether a parent snapshot can also be used that has a different absolute path than the current one. In this case, are only the metadata compared or the entire files read again.
I have an almost identical directory tree under a different path and have tried a backup with --parent and --ignore-inode, but apparently all files are read anyway. (Otherwise, processing would have to be significantly faster.)
But I don’t know how to check that either…
No, only the information from a parent snapshot is used where names and dates are exactly identical. That means you can specify a parent snapshot with a different path, but then it will be treated like you have removed that path and added new path - with the result that the new path will be completely scanned.
Thank you for the information! It is a pity that restic is not more comfortable and cannot work with relative paths.
restic can work with relative paths but it resolves them to absolute paths when saving files.
Can you specify your use case more precisely? Talking about parent snapshots is only a performance issue. Here you talk about being comfortable which seems to be something different. Can you specify what you mean by “almost identical” an what you would expect restic to do?
Example:
I have two external HDDs whose contents are synchronized from time to time “in the field”. So they are always slightly different, but almost the same. If one of them comes to my office, I would like to backup the contents into the repo.
So that --parent works and not all file contents have to be read again, I always have to manually mount the source files on the same absolute moutpoint. Using the automatic mounting (/media/ on Linux or /Volumes/ on MacOS) then the HDDs must have the same volume label, which makes trouble with direct syncing between the HDDs.
It would be convenient not only in this case, if you could also specify the relative path instead of the absolute path.
Backup solution proposal:
restic -r <repo> -p <pwdfile> backup /Volumes/marjorie02 --relative-path
should overwrite the saved snapshot path from /Volumes/marjorie02 to ./
But I’m overall not sure if that would make sense because the host name and path are used to uniquely identify backups in the snapshot list. It could also interfere with the automatic parent search. I think it would make sense to allow only the usage of relative paths for the manually selection of parent snapshots:
restic -r <repo> -p <pwdfile> backup /Volumes/marjorie02 --relative-parent <snapshot>
In this case, a parent snapshot with any path would work with the backup data, because it would both be treated as if it were under the same path.
When restoring it should be possible too to use relative paths (not just because of the parent snapshot, but in general. It occurred to me now that this is a bigger topic. Would be worth a thread of its own?)
Restore solution proposal:
restic -r <repo> -p <pwdfile> restore <snapshot> /Volumes/marjorie01/ --relative-path
should cut off /Volumes/marjorie02 and restore only the path below into /Volumes/marjorie01/. That would be possible in any case, because only the absolute path before the top backup data directory has to be cut-off.
I think it is important to introduce this option in some way. It is extremely annoying that the absolute path is always used when restoring. If the path to the backup data is “endless”, it is uselessly mounted or restored exactly that way, instead of using the real top of the backup files.
What do you think?
I think this feature would be useful, and your external-HDD use-case is one good example.
Another example: it would have been useful for me when I first started with restic, and needed to import my rsnapshot/hardlink-based backup into a new restic repo. Some info on the scripts I ended-up using can be found in response to this question. TLDR; to overcome the problem of paths I chose to symlink to each snapshot in turn and then pointed restic through the symlink. It would have been a lot more elegant to simply point restic to each snapshot path, while telling it to remove (or replace) the absolute location.
By the way, you could also apply the symlink workaround to your use-case.
Could this be a topic for a future version of restic?