fix(backup): group retention by host,tags so path edits stop freezing series (1.10) - #576
Merged
Conversation
… series (1.10) restic's default is --group-by host,paths, and that default is the bug. Each distinct path set gets its own independent 7/4/6, so editing a backup's path list does not shorten the old snapshots' retention -- it starts a new series and freezes the old one with permanent history. keep-daily 7 keeps the seven most recent days that HAVE snapshots, not the last seven calendar days, so a group receiving no new writes never ages out at all. Measured before changing: 203.666 GiB across 61 snapshots on R2, 13 still carrying a 224.7 GiB VHDX removed from the backup on 2026-08-13. Grouping by tags puts every nas-tagged snapshot in one series so those age out naturally once six newer months exist, around Feb-Mar 2027. Nothing is deleted today and no irreversible decision is required. This dissolves 1.10's central dilemma and reconciles the entry with itself: the original text said the VHDX would linger until 2027-02, the 08-29 correction said forever, and both were right -- the correction describes the default grouping, the original describes a sane one. The disagreement was a flag neither version had checked. The repo already knew: backup-cloud.yml has used --group-by host,tags since the same class of bug hit it, commented 'if a source path ever varies again, retention still works'. One of four forget sites had the fix. This propagates it to the other three. It also explains why the downstream fixes could not have worked. The offsite copy is unfiltered -- restic copy transfers every source snapshot not already in the destination -- so forgetting the 13 on R2, or emptying the bucket and re-seeding, would re-upload 203 GiB on the next run. The cause is upstream, so all three repos change together.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
restic's default is --group-by host,paths, and that default is the bug. Each distinct path set gets its own independent 7/4/6, so editing a backup's path list does not shorten the old snapshots' retention -- it starts a new series and freezes the old one with permanent history. keep-daily 7 keeps the seven most recent days that HAVE snapshots, not the last seven calendar days, so a group receiving no new writes never ages out at all.
Measured before changing: 203.666 GiB across 61 snapshots on R2, 13 still carrying a 224.7 GiB VHDX removed from the backup on 2026-08-13. Grouping by tags puts every nas-tagged snapshot in one series so those age out naturally once six newer months exist, around Feb-Mar 2027. Nothing is deleted today and no irreversible decision is required.
This dissolves 1.10's central dilemma and reconciles the entry with itself: the original text said the VHDX would linger until 2027-02, the 08-29 correction said forever, and both were right -- the correction describes the default grouping, the original describes a sane one. The disagreement was a flag neither version had checked.
The repo already knew: backup-cloud.yml has used --group-by host,tags since the same class of bug hit it, commented 'if a source path ever varies again, retention still works'. One of four forget sites had the fix. This propagates it to the other three.
It also explains why the downstream fixes could not have worked. The offsite copy is unfiltered -- restic copy transfers every source snapshot not already in the destination -- so forgetting the 13 on R2, or emptying the bucket and re-seeding, would re-upload 203 GiB on the next run. The cause is upstream, so all three repos change together.