Does parent selection during backup consider tags?
I have two backup jobs, warm and full. They select the same paths, while warm has a larger list of excludes, and the jobs are tagged differently.
I run warm multiple times and then a full backup. After testing, I’ve noticed that the full backup takes a long time when run in this order, because it’s selecting a parent from the warm backup set, which causes re-hashing of all the data in full but not in warm.
Parent snapshot usage questions for parent selection performance impact)
Searching around the forums and docs, I can’t find great info on how parent selection should work. Based on above, it seems to group by paths,host to pick the most recent snapshot. Is this correct?
Other (perhaps incorrect) posts seem to indicate that it should group by paths,host,tags:
This is most likely why it’s taking so long, but it’s not re-uploading everything.
Restic looks for a so-called “parent” snapshot. It compares metadata with the parent to decide what it can safely skip. For example, a file with the same exact name, size, timestamps, ownership, permissions, etc. is seen as not changed without ever looking at its contents.
Without a parent snapshot, restic chunks and hashes every single file, just as before – however, it will find most of those chunks in …
A parent snapshot can be specified with the
--parent option. If one is not specified, restic looks for the most recent snapshot with exactly the same hostname, path set, and tag set.
Tags are currently not considered when selecting a parent snapshot. The parent snapshot selection essentially just looks for the latest snapshot from the same host with the exact same paths.
Would this be a useful option to add? I use --group_by tags,host with forget, which hints at using this grouping behavior for snapshots as a thing people might want to do.
Maybe use the same option and semantics for the backup command to determine a parent?
The suggestion sounds useful. But we probably should clean up the parent snapshot selection code first… For now a feature request on Github would nevertheless be useful.