Thanks, makes sense on one level.
After thinking about it I realise that restic is significantly different to rsync (used with
--link-dest, i.e. hard links), in the sense that if you did an rsync backup, even if things had not changed, you would be creating thousands of hard links (which do occupy a finite disk space, and do take time to create and also to delete), whereas with restic this doesn’t apply.
BUT… in terms of pruning of old snapshots there seems to me to be a potential issue: if you are doing hourly snapshots, and you decide that you want to keep the last 5 hourly snapshots where things have changed, how would you do that? It wouldn’t matter if in fact over the past 10 hours you had done one or two “no change” snapshots, but how do I in fact know when the quota of 5 “things changed” snapshots has been reached, and also how do I know which is the oldest “things changed” snapshot?
I think I would want to identify the oldest “things changed” snapshot, and then prune it, but also prune any “no change” snapshots which were older than the next most recent “things changed” snapshot (i.e. the oldest one which I was planning to keep for the moment).
If there’s no way I can distinguish between “things changed” and “no change” snapshots, pruning (i.e. in this example, automatically pruning the oldest snapshot where there are 6 of them) might in fact leave you with 0 “things changed” snapshots. This would arise where you hadn’t changed the source files over the past 5 hours, but the restic snapshot hourly job had continued to function.
Of course, with restic I can’t just run a
diff-type command, as I can with rsync, because everything’s cleverly packaged in a repository (and encrypted).
Maybe the answer to this problem is what you referenced, the “dry run” thing in prune. Or maybe the info about how much additional disk space was needed by a given snapshot is kept with it in the repo? If this was 0 you would obviously know this was a “no change” snapshot.
I’ll look into these things today, hopefully.