# REPORT — night 2026-10-22 → 23: the stray-copy fix and the review fixes, nothing released

**What:** the night brief's controller parts (Part 1, the controller findings of Part 3). No release, no floor change.
Design read: `07-backup-architecture.md` §6.3, §8 (R-1180's guard), now §8.2b.

## Part 1 — the stray-copy fix (`66a69d4`, `912e592`)

The capped second-drive copy (R-1214) runs `rsync -a --delete` in its own container. A timeout, a controller restart
or a self-update killed only the `docker` CLI — the container went on deleting, outside every guard the controller
holds. Now:
- each copy container has a fixed name (`felhom-tier2-copy-<app>-<8 hex>`) and the label `felhom.tier2-copy=1`;
- a leftover of the same copy is removed before a new one starts; on any error, the timeout included, it is removed by
  name;
- at start, BEFORE the scheduler and the web server, every labelled container is removed (each logged; retried every
  minute until it succeeds; restores refused meanwhile);
- a restore is refused while any second-drive copy runs or a leftover may run;
- review C4/C7 in the same function: `--mount` (a path the daemon does not see is refused instead of created empty),
  the controller's image ID with `--pull never`; `--no-healthcheck` (the 9202 proof showed the inherited health check).

**Tests** (Docker-free seams): `TestStrayCopy_*` — 8 in `internal/backup`, 1 web, 1 wiring; each seen failing with its
mechanism removed. **9202 proof** (felhom.eu `audits/night-2026-10-23/P1-straycopy/`): rc.5; a controller restart in
the middle of a 16 GB copy → the new controller removed `felhom-tier2-copy-immich-948f2280` at start; a restore probe
during the copy was refused; the redone copy equals the source (54 s); a 15 s test build (rc.5 + a binary with the
limit set by ldflags, never pushed) → the timed-out container removed, the partial copy stopped growing. 9202 back on
0.339.0, test files and the test image removed.

## Part 3 — review findings (controller), verified at file:line

| # | Finding | Verdict |
|---|---|---|
| C1 | the copy container outlives the CLI | REAL → fixed (Part 1) |
| C2 | two more import paths merge old and new data | REAL, pre-existing in 0.339.0 → R-1187 (recovery code: red-proof + 9202 proof first); not a hold |
| C3 | the R-1187 (c) refusal also catches an unhealthy app, with wrong advice | REAL → text fixed (`943c517`); the import path → R-1187 |
| C4 | `-v` creates a missing path on the daemon side | REAL → `--mount` (`66a69d4`) |
| C5 | the catch-up holds the whole-guest backup while its slow checks run | REAL → fixed (`943c517`, `TestC5_*`, red-proved) |
| C6 | two comments overstate the proof's catch-up | REAL → fixed |
| C7 | the image tag, not its ID; no `--pull never` | REAL → fixed; „no memory cgroup → uncapped": NOT-A-FINDING (every Felhom guest is an LXC on a cgroup-v2 Proxmox kernel; the guest's own memory figures come from it) |
| C8 | README: „out of every backup" | REAL → fixed (the `.fab` export and the whole-guest snapshot still hold it) |

**Images:** `0.340.0-rc.5` (= `66a69d4`), `0.340.0-rc.6` (= `943c517`, on tonight's test box). CI: `66a69d4` 2227,
`912e592` 2228 green; `943c517` and the docs commit: see felhom.eu `REPORT-night-2026-10-23.md`.