admin
d0cec9d3f3
F-CRIT-2 marked SHIPPED + PROVEN-LIVE: NewestArchiveTime now counts only plausibly-complete entries (measured 1 MiB floor), verified by replaying campaign fault 2 on demo-hp in both directions. Files two follow-ups: - R-99: prune never REMOVES phantoms. It does NOT count them toward keep-last (dry-run kept 2 real + the phantom), so there is no retention/data-loss bug — but they accumulate one per aborted upload. - F-CRIT-1: filed READY-HIGHEST. Campaign 8's other HIGH finding, untouched by this fix.
41 lines
2.5 KiB
Markdown
41 lines
2.5 KiB
Markdown
# REPORT — F-CRIT-2 fixed: a failed backup no longer looks like a fresh one (2026-07-28)
|
|
|
|
Scope: `felhom-agent` v0.105.0 → **v0.106.0**. Docs here. Implementation detail and the full live
|
|
re-test live in `felhom-agent/REPORT.md`; the campaign that found it is
|
|
`documentation/audits/CAMPAIGN-8-backup-restore-2026-07-27.md`.
|
|
|
|
## What changed
|
|
`NewestArchiveTime` counted an aborted PBS upload (1 byte, manifest-less, and NEWEST) as a
|
|
successful backup, so the tier read fresh, went **not due**, and was never retried — seven days of
|
|
silence on the real 168h cadence, invisible to both the R-88 breaker (defers only *due* tiers) and
|
|
the hub deadline monitor (reads the same freshness). It now counts only *plausibly complete*
|
|
entries via a measured 1 MiB floor; undecidable ⇒ not counted.
|
|
|
|
**Size is the only tier-agnostic discriminator.** `verification` and `encrypted` are absent on every
|
|
local (dir) archive AND on a good PBS snapshot until `verify-new` catches up — gating on either
|
|
would have rejected 100% of local backups and produced fleet-wide backup thrash. That inverse risk
|
|
is a first-class test, red-proofed by making the filter reject everything.
|
|
|
|
## Verified live, not just in unit tests
|
|
Campaign fault 2 was replayed against the fixed agent on demo-hp — phantom created, rejected and
|
|
announced once; the tier correctly reported DUE and backed up (4,359,968,099 B landed); and the
|
|
inverse showed **no thrash**, with 91 scheduler ticks as the positive observable that the loop was
|
|
alive rather than dead.
|
|
|
|
## Settled along the way — no retention bug
|
|
Server-side prune does **not** count phantoms toward `keep-last`: a dry-run against three real
|
|
snapshots plus a phantom retained two real ones plus the phantom. The feared "two phantoms ⇒ zero
|
|
real backups" does not occur. Prune never removes them either, so they accumulate one per aborted
|
|
upload — filed as **R-99** (LOW, hygiene), not as a retention bug.
|
|
|
|
## Docs touched
|
|
- `documentation/backlog/OPEN-ITEMS.md` — F-CRIT-2 → SHIPPED+PROVEN-LIVE; **R-99** filed;
|
|
**F-CRIT-1** filed as READY-HIGHEST (Campaign 8's other HIGH finding, untouched here).
|
|
- `documentation/audits/CAMPAIGN-8-backup-restore-2026-07-27.md` — F-CRIT-2 row struck through and
|
|
a closing section added.
|
|
|
|
## Still open, highest first
|
|
**F-CRIT-1** — an app that fails to restart after a quiesce never alarms, for two independent
|
|
reasons. Then fault 4 (restic transport interruption), which this fix makes more pointed: the
|
|
phantom question is now answered for PBS and still open for restic.
|