fix/1 10 group by host tags - #577
Closed
swares wants to merge 2 commits into
Closed
Conversation
swares
commented
Sep 6, 2026
Owner
- fix(backup): group retention by host,tags so path edits stop freezing series (1.10)
- fix(backup): group retention by host,tags; deepen cold-sec to match (1.10)
… 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.
…1.10) restic's default is --group-by host,paths, and that default is the bug. Each distinct path set gets its own independent policy, 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 N keeps the N most recent days THAT HAVE snapshots, so a group receiving no new writes never ages out at all. Measured with forget --dry-run on all three repos before changing anything, and the measurement corrected the plan twice. First: this does remove snapshots immediately -- 17 at the primary and offsite, 22 at cold-sec -- where I had claimed it would remove nothing today. Under one merged series the union of daily-7/weekly-4/monthly-6 collapses to about twelve; the primary held 29 only because each frozen path-set had private daily slots. Twenty-nine was the bug, not the baseline. Second: two VHDX-bearing snapshots survive as the June and July monthlies, and restic dedupes, so either one pins the full 224 GiB. No space is freed until those age out around Jan-Feb 2027 -- which vindicates this entry's ORIGINAL estimate over its 08-29 correction. The correction was right about the default grouping, the original about a sane one, and the entry disagreed with itself for a week over a flag neither version had checked. copy_keep_daily 14 to 21 as a direct result: at 14, cold-sec would have dropped Aug 14, 15, 17, 18, 19 and 20, and the primary drops those too, so six days that exist today would have gone from both local repos. The primary was deliberately not raised instead -- deepening it past cold-sec would invert the hierarchy documented eleven lines above the value being changed. Offsite stays at 7/4/6 since R2 is the one repo where depth is billed. 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.
Owner
Author
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.