Files
felhom.eu/documentation/audits/dataloss-hunt-2026-10-20/C2-verdicts.md
T

8.3 KiB
Raw Blame History

C2 — the main session's verdict on every candidate (2026-10-20)

Method: each candidate's file:line read in LIVE source (controller 7ca59e2 = v0.336.0, agent 4e1621c, felhom.eu 5c48731+); then (a) the register searched, open AND closed, with ASCII fragments — positive control R-893 found in both; (b) the design test against 07-backup-architecture.md and CONTEXT.md. Verdict words:

  • CONFIRMED — the mechanism read true in live source AND a proof ran (unit test against production code, or live).
  • CONFIRMED-CODE — the mechanism read true in live source; no proof ran yet.
  • PLAUSIBLE — the reviewer's reading, spot-checked only.
  • NOT-A-FINDING — with the reason.

Register: none of the candidates below is in OPEN-ITEMS or CLOSED-ITEMS (searches in C2-register-search.txt).

id verdict design or defect note
D1 shares second-drive copy pruned by another drive's group CONFIRMED (unit test, production code, fake mirror seam — C3-D1-shares-tier2/) defect Worse than reported: with shares on two drives that pick the same target, EVERY night the second group's reconcile deletes the first group's copy (removed stale dest dir hdd_2/b_share) — one drive's shares never have a second copy while the run says ok. And the night a drive goes away, its copy is deleted (removed stale dest dir hdd_3/csaladi_fotok).
D1b an AWAY drive is still chosen as the second-drive target CONFIRMED-CODE (+ the same unit test: hdd_3/iskola => hdd_1/... after hdd_1 was marked disconnected) defect tier2.go:151-180 loops GetSchedulableStoragePaths() (settings.go:1593-1603 excludes only Decommissioned); no Disconnected check. On a real box the away drive's empty mount point is on the guest's root disk
K1 reinstall after „delete the old host" loses the route to the old escrow CONFIRMED at the hub store (unit test against production code, C3-K1-escrow-after-host-delete/); the controller half (new key minted, history set aside on night one) CONFIRMED-CODE defect (03 §8a / 07 §7.0 promise the route; D19+R-1154 removed it unrecorded) hub store.go:3164-3229 demotes into host_escrow_superseded under the OLD host_id and deletes the hosts row; GetEscrowStatusForCustomer store.go:3499-3527 joins on hosts → nil for the new box; customer_reset.go:48,155 and store.go:4189 DO include host_deletions. Live proof needs Tester4 off-site ON (B7)
K2 abandoning one set-aside copy purges every retained package CONFIRMED-CODE (store.go:4185-4190) → R-1182 defect (breaks store.go:4176-4179's own invariant) store.go:4185-4190 customer-wide delete read true
R1/D4 a failed LOCAL unit restore: no copy of the live state, app started anyway CONFIRMED LIVE on 9202 (C3-R1-local-restore-9202/): live row destroyed, DB crash-loops, no undo copy, raw English Docker text to the household design question for the operator: decision 154 (R-638 A) chose „start anyway"; D20 (R-893 A) gave „put back exactly" to the OFF-SITE path only restore_unit.go:428-489
R2 a crash mid-restore starts the app on a mixed state; the undo copy is never read at start PLAUSIBLE defect appstop_marker.go:307, offbox_restore_undo.go:137
R3 a cut-off shares restore can be placed and reported restored CONFIRMED-CODE defect (R-358 class, fixed for apps, not shares) shares_restore.go:131-140 readiness = non-empty dir
R4 .fab export drops a drive folder holding a symlink PLAUSIBLE defect appexport/fabplan.go:292, export.go:714
R5 second-drive whole restore: files swapped, then the unit half refuses → app left STOPPED, text says „untouched" CONFIRMED (unit test, production code: C3-R5-whole-restore/ — 1 file restored + 1 replaced, app stopped, no start, message „az alkalmazás és az adatai érintetlenek") defect tier2_whole.go:301-340: stop + merge, then RestoreFromRecoveryUnitAtWith whose early refusals return before its own stop/start; hu.json err.backup.unit_versions_mixed „Az alkalmazás érintetlen"
R6 .fab import into a stopped app merges volumes PLAUSIBLE defect appexport/restore.go:361-374
R7 .fab import has no guard / undo / record PLAUSIBLE defect
R8 .fab import drops the family gate CONFIRMED LIVE on 9202 (C3-R1187e-fab-family-gate/: stranger 401 before, 200 after the import) → R-1191 (P1) defect cmd/controller/main.go:3517-3530, stacks/family_gate.go:173-190
R9–R11, R13, R14 PLAUSIBLE defect / design (R13) low
R12 interrupted whole restore leaves *.felhom-restoring, every retry fails CONFIRMED (unit test: C3-R12-leftover-temp/) → R-1188 (c) defect tier2_whole.go:86-87 O_EXCL; removed only on an in-process error
D2 a missing / emptied app folder deletes its second-drive copy within one night CONFIRMED for a MISSING folder (unit test, production code + real copy seam: C3-D2-missing-leg/ — mirror of photos deleted, run „ok", the warning says only „nem kerültek a másodlagos mentésbe"); the EMPTIED case CONFIRMED-CODE (rsyncMirror = rsync -a --delete, tier2.go:744-751; the test seam does not delete) defect-shaped corner of a choice: 07 §8.2 „data legs are NOT guarded" is about a leg LEAVING the class set; this is a declared leg that is MISSING, which the code itself logs as a gap (tier2_capture.go:55-61) and then reconciles away (tier2.go:454) P1 for optional legs (no other tier holds them)
D3 / T11 a host clock ahead silences the whole-guest tier; the hub reads the same clock PLAUSIBLE (B6 #8 on the rehearsal VM is its live test) defect agent localapi/server.go:1178-1190
D5 a dump that fails its own check has already replaced the good one CONFIRMED (unit test with a docker stub: C3-D5-dump-replaced/) → R-1185 defect for the ORDER appbackup/dbdump.go:388-422: size check, rename (:399), then ValidateDump
D6 kept-data page can list a running app's folder PLAUSIBLE defect needs an unreadable app.yaml
D7 unit restore can point the app at an old drive PLAUSIBLE (low) defect
D8 local whole-guest keep=1 design (07 §6.1 R-684 chose it) design NOT-A-FINDING: the operator chose keep=1 for demo-hp; recorded in 07
T1 the nightly mirror (rsync --delete) can run during a restore from that mirror CONFIRMED (unit test, production rsync mirror: C3-T1-mirror-during-restore/) → R-1180 defect RunAllTier2 (tier2.go:479-520) takes no backup flag; the whole restore holds only acquireRunning (tier2_whole.go:301)
T2 controller image without tzdata → UTC schedules NOT-A-FINDING: measured on 9202 (controller 0.331.0, Debian 13 base): /usr/share/zoneinfo/Europe/Budapest present, scheduler logs „scheduled for … CEST" —
T3 whole-guest start creeps ~5 min/night PLAUSIBLE defect needs the agent journal over weeks
T4 whole-guest quiesce stops apps mid-restore PLAUSIBLE defect quiesce.go:213-275
T5 nightly off-site copy skipped SILENTLY when the flag is held; catch-up never retries CONFIRMED-CODE → R-1186 defect (the code chose nil for the nightly path; the catch-up gap is not chosen) offbox.go:981-996, main.go:1246
T6 proof / integrity never run on a box off at 05:30–06:00 PLAUSIBLE defect (comment main.go:1575-1577 says the opposite)
T7 hub false „no DB dump" for late or evening W PLAUSIBLE defect hub monitor/deadline.go:416-419, 556-565
T8 the OS leg follows a daytime valve backup design question design 07 §6.1 / 11 §8.1 set no time bound
T9 hub daily jobs run TWICE on 2026-10-25 CONFIRMED (replay of the hub's exact arithmetic, C3-T9-hub-dst/replay.txt) defect deadline-check fires 04:00 CET AND 05:00 CET; db-snapshot twice (keep-2 → the previous day's copy pruned a day early). In five days, on the live hub.
T10 spring forward collision PLAUSIBLE defect (P4)
T12, T13 PLAUSIBLE defect (P4)
K3–K8 PLAUSIBLE K6 design

NFC/NFD (the brief's question for A.1.4): reviewer 1 found no normalisation anywhere — rsync, restic and the Go merge compare names byte for byte, so the missing-only compare sees two names for the NFC/NFD pair. The household data carries the pair; B8 measures it live.