Files
felhom.eu/documentation/audits/r1294-offsite-cap-2026-10-26/README.md
T

31 lines
2.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# R-1294 — demo-hp's weekly off-site clean-up refused by its own cap (read only, 2026-10-26)
## The rule (code)
- Controller `internal/backup/offbox_window.go:132` `offsiteGuard`: refuses a future-dated snapshot, a snapshot newer
than the hub allows, a removal younger than `keepDaily` (7) calendar days unless superseded the same day (R-824/R-867),
and **a plan larger than `maxRemove`** (`:152`). The policy: keep-daily 7, keep-weekly 4, keep-monthly 6, grouped by
host+tags (`:47-49`, `:82`).
- Hub `internal/offsitekeys/service.go:288` `MaxRemove(countBefore)` = **half of what is there, at least 5**. An operator
one-shot grant may raise it for one window (`store/offsite_keys.go:179` `GrantOffsiteWindowOnceMax`, R-833: „after a
long gap the honest backlog exceeds half the snapshots and the default cap refuses every window").
## demo-hp's store (read only, the box's own transport; `restic snapshots` + `restic forget --dry-run`, `--no-lock`)
- 359 snapshots, 18 groups (one per app). restic's own dry-run plan: **keep 150, remove 209**.
- **Every removal is 7–30 days old; none is younger than 7 days.** Every group keeps snapshots: the nine long-lived apps
keep 11 each (remove 16), the five media apps keep 9 (remove 11–13), rallly/grimmory keep 2 (remove 4), nextcloud and
vaultwarden keep their 1 (remove 0). No group loses its last copy.
- The bulk: **2026-10-16 holds 152 snapshots** (that day's test runs on demo-hp); every other day ~14 (one per app). The
keep-daily rule keeps one per day, so the extra ~138 of 10-16 go, plus the normal ageing-out.
**Verdict: the plan is honest** — superseded copies by the keep rule, nothing it should keep.
## Can it get back under the cap by itself? No.
Hub window history (`offsite_windows`, hub DB with its WAL): demo-hp 10-12 pruned 190→100; 10-19 pruned 324→261; **10-26
refused** (359, plan 209 > cap 179). Each refused week adds ~98 snapshots (14 a day) and nothing is removed, so the cap
grows ~49 a week while the plan grows ~84 (the normal ageing plus the stuck backlog): the gap widens every week, and the
box mails the operator an error each Sunday. demo-felhom (the 2026-10-05 refusal was pre-R-867) and Tester 1 pruned
normally today (63→48, 78→57) — only demo-hp has this shape, caused by one day of 152 test snapshots.