## 2026-09-16T17:17:39Z five photos into Nextcloud, through the app's own interface
  app front door: status.php -> 200
  MKCOL Fotok -> 201
  PUT nyaralas-1.jpg (200000 B) -> 201
  PUT nyaralas-2.jpg (400000 B) -> 201
  PUT nyaralas-3.jpg (600000 B) -> 201
  PUT nyaralas-4.jpg (800000 B) -> 201
  PUT nyaralas-5.jpg (1000000 B) -> 201
  total uploaded: 3000000 B in 5 files
  listing:
    
    nyaralas-1.jpg
    nyaralas-2.jpg
    nyaralas-3.jpg
    nyaralas-4.jpg
    nyaralas-5.jpg
## 2026-09-16T17:18:05Z pointing Nextcloud at the off-site tier
  POST /backup/offbox/toggle app=nextcloud enabled=1 -> http=302
  page now says: tkezés ↗ Biztonsági mentés — Távoli mentés enkicsifelhom.hu Aktív — nincs kijelölt alkalmazás Távoli mentés (3. mentés) — titkosított, offsite Az alkalmazás-mentések titkosított másolata egy távoli tárolóra — saját NAS vagy Felhom offsite tárhely — restic + SFTP kapcsolaton. A tároló csak titkosított adatot lát. Ez a 3-2-1 szabály „1 off-site" lába — függetl
## 2026-09-16T17:18:31Z running the tier-1 leg (the local app backup) on the fresh box
  POST /api/backup/run -> {"ok":true,"message":"Mentés elindítva"}
 http=200
  finished: {"ok":true,"data":{"db_dump":{"count":1,"duration":"22.245700003s","last_run":"2026-09-16T17:18:54.254096666Z","success":true},"enabled":true,"running":false}}
## 2026-09-16T17:19:20Z off-site toggle retried with the value the FORM uses (enabled=true, not 1)
  POST toggle enabled=true -> http=302
   app=nextcloud    next-value=false  (a toggle shows the value it would SET)
   header:  Biztonsági mentés — Távoli mentés — Felhom.eu Indítópult Vezérlőpult Alkalmazások Tárhely Meghajtók Hálózati tárhely Biztonsági mentés Áttekintés Táv
## THE TIER-1 LEG RAN on the fresh box, with the five photos already in place:
##   POST /api/backup/run -> 200 {"ok":true,"message":"Mentés elindítva"}
##   finished: db_dump count=1, duration 22.2 s, success=true
##   (One database, because Nextcloud is the only app on this box. The unit capture rides the same run.)
## MY SHORTCUT, caught by the page rather than by luck: the first off-site toggle POST returned 302 —
##   the SHAPE of success — and changed nothing, because I sent `enabled=1` while the form's own field
##   carries `enabled=true`. Reading the per-app row instead of the redirect is what found it.
## 2026-09-16T17:19:41Z running the TIER-3 (off-site) leg — this is what carries the photos off the box
  POST /backup/offbox/run -> http=302
  status now: {"ok":true,"data":{"db_dump":{"count":1,"duration":"22.245700003s","last_run":"2026-09-16T17:18:54.254096666Z","success":true},"enabled":true,"running":false}}
## THE OFF-SITE TOGGLE IS ON for Nextcloud: the row's form now offers `enabled=false`, which is how a
##   toggle says „currently on". Read from the row, not from the redirect — the first attempt returned
##   302 and changed nothing.
##   So on this box, an hour after the default shipped: tier 3 provisioned by the hub automatically,
##   and the household's one app pointed at it.
## 2026-09-16T17:2xZ THE BACKUP PAGE ON THE FRESH BOX — the good half and the gap, both measured:
##   Nextcloud · Adatlemez · 62.2 MB
##     „1. mentés  Auto  helyi  Utolsó: 1 perce   DB + Konfig"
##     „Az alkalmazás fájljait a távoli másolat (és a második meghajtó) védi — ez a helyi mentés a
##      beállításokat és az adatbázist tartalmazza."
##     „2. mentés  … Nincs 2. (off-drive) másolat"
##     „3. mentés  Kulcsletétre vár · A távoli mentés a titkosítási kulcs letétbe helyezéséig szünetel"
##   „DB + Konfig + Adatok" appears ZERO times on this page — R-537 holds here too: the tier-1 row
##   does not claim to hold the app's files.
##   AND THE GAP (R-543): off-site is ON by default and PAUSED, waiting for the escrow ceremony that
##   nothing asks the household to perform. `POST /backup/offbox/run` -> 302 and produced no snapshot;
##   the controller log shows only `offsite-credential-retry`, no restic activity. So on day one the
##   sentence above promises protection by a copy that does not exist yet.
## A TRAP THIS PROJECT ALREADY KNOWS, hit again and recorded: my `grep -oE` with an accented pattern
##   („Helyre…") died with „exceeds complexity limits" and told me nothing, while two guessed paths
##   (/backups/escrow, /escrow) 404'd. Parsing the page in Python with the ASCII fragment „Helyre"
##   found the link at once: /backup/escrow („Helyreállítási kód létrehozása").
##   The standing rule is „never let an accented pattern gate a conclusion" — the failure mode here
##   was not a false 0 but a dead tool, and the cost was the same: two wrong guesses.
## THE ESCROW CEREMONY PAGE (/backup/escrow), in the household's own words:
##   „1. Előfeltételek ellenőrzése — Ellenőrzés folyamatban…"
##   „2. Fontos tudnivalók — A helyreállítási kód a mentései utolsó kulcsa. Pontosan egyszer jelenik
##    meg — a rendszer sehol nem tárolja, és a Felhom sem ismeri. Ha a szerver megsemmisül, a távoli
##    mentések CSAK ezzel a kóddal állíthatók vissza."
##   So the ceremony is customer-facing, honest about what the code is, and shows it exactly once.
##   That is also why this walk captures it into an out-of-band 0600 file at the moment it appears:
##   the off-site restore later in this phase cannot happen without it, and nothing can re-issue it.
## 2026-09-16T17:2xZ THE ESCROW CEREMONY CANNOT START YET — preflight, verbatim:
##   agent_supported: true · escrow_state: „pending"
##     pbs_storage_id   NOT OK — „escrow.pbs_storage_id not configured"
##     dr_tier          NOT OK — „DR tier not applied on this host"
##     age_binary       ok — /usr/bin/age
##     hub_upload       ok — hub upload target configured
##     staged_secret    ok — staged secret present
##     sudo_grant       ok — sudo grant listed (list-mode)
##   So four of six prerequisites are already in place on a box that installed itself an hour ago;
##   the two red ones are the PBS-DR cascade (host → WG peer → apply), which is precisely what the
##   ep0 grant of this morning (R-534) exists to unblock. The hub had said at 17:05 that the
##   descriptor „applies once the cascade is ready (host → WG peer → apply)" — a host now exists.
##   Checked next on the hub side; whatever it says is the end-to-end verdict on that grant.
## THE CASCADE, in the hub's own words (customer page, DR tier widget):
##     done     „host enrolled (tester-1-33b6a9)"
##     done     „WG tunnel peer registered"
##     waiting  „provisions automatically when the WG peer registers"
##     waiting  „ceremony possible once the descriptor is applied on the box"
##   and the agent's capability list on the SAME page:
##     „escrow-ceremony  critical  inactive — customer recovery-code ceremony (controller-driven)
##      — disabled by configuration"
##     „pbsdr-create / pbsdr-grant / pbsdr-read  inactive — disabled by configuration"
##   The WG peer really is registered: ep0 shows FIVE wg peers with fresh handshakes, and the hub
##   pushes them every five minutes („wgsync: pushed 5 peers").
##   So the chain stops at the APPLY step, because the agent's PBS-DR capabilities are switched off by
##   configuration — not because ep0 refused anything. This morning's grant (R-534) is therefore still
##   unproven end-to-end: nothing has yet asked ep0 to do the thing the grant allows.
