docs: R-200 Part 0 shipped; R-203 recorded (mandatory userdata dir missing from the offsite snapshot while the run says ok)
gates / gates (push) Successful in 9s

This commit is contained in:
2026-08-04 15:00:40 +02:00
parent 1b1366bb6e
commit 532f5712a8
2 changed files with 58 additions and 49 deletions
+27
View File
@@ -1672,6 +1672,33 @@ Last updated: 2026-06-13 (v0.60.0 backlog-Medium cleanup)
---
## R-203 (2026-08-04) — a MANDATORY userdata directory can be absent from the off-site snapshot while the run says `ok`
Found live on demo-hp while staging the R-201 drill, and it **halted that drill**.
`NamespaceRoot(drivePath, inGuestDrive)` (`appbackup/paths.go:28-33`) appends the `felhom-data` segment
**when the drive IS the system data path**`m.namespaceRoot` = `NamespaceRoot(drivePath, drivePath !=
m.systemDataPath)` (`backup/backup.go:331`). The deploy-time bind does not: `${USERDATA_PATH}` is
`<HDD_PATH>/userdata` (`stacks/classify_binds.go:14`).
With `system_data_path: /mnt/sys_drive` and `calibre-web` deployed at `HDD_PATH=/mnt/sys_drive`:
live bind (files land here): /mnt/sys_drive/userdata/media/books ← exists
capture set looked for: /mnt/sys_drive/felhom-data/userdata/media/books ← does not
**The same compose used BOTH roots**`${IMPORT_PATH}` resolved *with* the segment,
`${USERDATA_PATH}` *without*. The run logged one `[WARN] mandatory data path missing on disk, skipped
from offsite`, then `0 mandatory path(s)` and **`backup OK: 3 app(s), 3 snapshot(s)`**, with
`last_status: ok`. Nothing customer-visible or hub-visible said the directory was dropped.
**Not established:** whether `HDD_PATH == system_data_path` is a supported deploy. It was accepted
(HTTP 202) one call after the NAS path was correctly refused (R-108). **Either branch is a defect**
broken resolution, or a missing refusal.
**Two things a fix must do:** make the two roots one function, and make a skipped **MANDATORY** path a
customer/hub-visible signal rather than a container-log WARN. `opengist`/`privatebin` declare no
mandatory userdata paths and are unaffected.
## R-200 (v0.195.0) — the offsite key recovery diagnostic
`--recover-offsite-check` is a `docker exec` escape hatch (the `--print-reset-code` shape), NOT a page