## F10 - a child deletes the photo folder (Nextcloud) - 2026-09-16T11:01:38Z
  seed: folder 'Fotok' created through Nextcloud WebDAV (the app's own file interface), MKCOL 201,
        5 files nyaralas-1..5.jpg, 200k/400k/600k/800k/1000k = 3 000 000 B total, every PUT 201.
  on-disk: 68204151	/mnt/felhom-drives/adatlemez/appdata/nextcloud
  on-disk: 5
  on-disk: 25337	/mnt/felhom-drives/adatlemez/backups
  2026-09-16T11:01:57Z pressing 'Mentes most' on the app-backup page (POST /api/backup/run)
  trigger: {"ok":true,"message":"Mentés elindítva"}
 http=200
  2026-09-16T11:02:58Z backup finished; status: {"ok":true,"data":{"db_dump":{"count":2,"duration":"47.936765144s","last_run":"2026-09-16T11:02:45.477832211Z","success":true},"enabled":true,"running":false}}
  restore page after the app backup:
    TEXT: Pillanatkép: — Válasszon alkalmazást — Még nincs mentés felhasználói adattal. A visszaállítás felülírja az alkalmazás jelenlegi adatait a kiválasztott mentés állapotával. Az alkalmazás a folyamat során automatikusan leáll és újraindul. Megértettem, visszaállítás indítása. Visszaállítás indítása Importálás mentett csomagból (.fab) Hordozható mentéscsomag (.fab) Hordozható pillanatfelvétel — bárhol tárolhatod, és bármikor visszatöltheted egy meghajtóról. A folyamatos védelmet az 1–3. szintű mentés adja. Jelszavas titkosítás (opcionális) Üresen hagyva a csomag titkosítás nélkül készül. Nextcloud Letöltés (.fab) Paperless-ngx Letöltés (.fab) PrivateBin Letöltés (.fab) Vaultwarden Letöltés (.fab)
  2026-09-16T11:05:06Z the child deletes the folder: DELETE /Fotok http=204
  folder after the delete: PROPFIND http=404  (404 = gone)
## MEASURED before the restore attempt:
##  1) The app backup ("1. mentes", tier 1) was made at 11:02:45Z by the customer-visible "Mentes most"
##     button (POST /api/backup/run -> {"ok":true,"message":"Mentes elindItva"}; the backup folder grew
##     25 337 B -> 978 MB, so the button does more than its status field, which reports db_dump only).
##  2) Its manifest lists db-dumps + THREE docker volume dumps (html, db_data, redis). It does NOT list
##     the drive-side app data (/mnt/felhom-drives/adatlemez/appdata/nextcloud), where the photos live.
##  3) Proof by listing the html tar (29 346 entries):
##       positive control "version.php" = 3 hits   (the listing works)
##       "data/" entries = 1284, but "./data/" is the EMPTY bind-mount point
##       "Fotok"   = 0 hits
##       "nyaralas"= 0 hits
##     And: find over the whole backups tree for *appdata*/*hdd*/*Fotok* = nothing.
##  4) The whole-guest backup does not cover them either - vzdump log of the 12:27 CEST run:
##       "including mount point rootfs ('/')", "including mount point mp0 ('/var/lib/felhom')",
##       "excluding bind mount point mp8 ('/mnt/felhom-drives') from backup (not a volume)".
##  5) The app-backup page nevertheless labels tier 1 "DB + Konfig + Adatok" and prints "Nextcloud
##     Adatlemez 65.1 MB" - a size measured on exactly the data it does not copy.
##  6) Tier 2 ("off-drive masolat") and tier 3 (offsite) both read "Nincs beallitva" on this box.
  2026-09-16T11:06:56Z pressing the restore button: POST /backup/restore stack_name=nextcloud snapshot_id=helyi
  restore POST http=302
  2026-09-16T11:07:42Z restore status: {"ok":true,"data":{"running":false,"op":"restore","stack":"nextcloud","started_at":"2026-09-16T11:06:56.710474757Z","last":{"op":"restore","stack":"nextcloud","ok":true,"message":"A(z) nextcloud: 3 adatkötet és az adatbázis visszaállítva — az alkalmazás újraindult.","finished_at":"2026-09-16T11:07:31.194473339Z"},"last_recent":true}}
  after the restore, through Nextcloud's own interface:
    PROPFIND /Fotok http=207
      file: 
      file: nyaralas-1.jpg
      file: nyaralas-2.jpg
      file: nyaralas-3.jpg
      file: nyaralas-4.jpg
      file: nyaralas-5.jpg
    GET /Fotok/nyaralas-1.jpg http=503 bytes=276
    trash PROPFIND http=207
      trash: 
  RE-MEASURE at 2026-09-16T11:08:38Z, app healthy (nextcloud Up >2 min):
    app status.php http=200   <- positive control, app is serving
    PUT control kontroll.txt http=201   <- positive control, WebDAV write works
    GET control kontroll.txt http=200 bytes=6   <- positive control, WebDAV read works
    GET /Fotok/nyaralas-1.jpg http=404 bytes=249
    GET /Fotok/nyaralas-2.jpg http=503 bytes=276
    GET /Fotok/nyaralas-3.jpg http=503 bytes=276
    GET /Fotok/nyaralas-4.jpg http=503 bytes=276
    GET /Fotok/nyaralas-5.jpg http=503 bytes=276
    body of the failed download (first 200 chars):
      <?xml version="1.0" encoding="utf-8"?><d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">  <s:exception>Sabre\DAV\Exception\NotFound</s:exception>  <s:message>File with name /Fotok/nyaralas-1
## RESULT - F10 (a child deletes the photo folder, Nextcloud, fresh box, one drive, no tier 2/3)
##  customer saw: the folder and the 5 photos vanish from Nextcloud (DELETE 204, PROPFIND 404).
##    After the restore the folder is BACK and lists all 5 photos - but NONE of them opens:
##    GET nyaralas-1..5 = 404 / 503 x4, body "Sabre\DAV\Exception\NotFound".
##    Positive controls at the same moment: status.php 200, WebDAV PUT kontroll.txt 201, GET 200 (6 B).
##    So the failure is real, not a starting app and not a broken login.
##  box did: POST /backup/restore (stack_name=nextcloud, snapshot_id=helyi) -> 302, finished in 35 s,
##    "A(z) nextcloud: 3 adatkotet es az adatbazis visszaallitva - az alkalmazas ujraindult."
##    It replayed the 3 docker volumes + the MariaDB dump. The DB dump (11:01:45Z) KNOWS the 5 photos,
##    because they were uploaded at ~11:00Z. The BYTES were never in any backup (see MEASURED above).
##  time to steady: 35 s restore, app healthy ~50 s later.
##  how much was lost: all 5 files, 3 000 000 B - every photo the folder ever held.
##  does the page say so? NO. The result line says the volumes and the database were restored and the
##    app restarted. Nothing says the app's files on the data drive are not part of this backup, and
##    nothing says the restored database now points at files that do not exist.
##  where the bytes actually are: Nextcloud's OWN trash on the data drive -
##    appdata/nextcloud/admin/files_trashbin/files/Fotok.d1789556707/nyaralas-1..5.jpg (all 5 present).
##    But the restored database no longer lists them: the trash PROPFIND returns an EMPTY list, so the
##    customer cannot press "restore from trash" either. The restore made the trash unreachable.
##  alarm fired and true? none fired.
##  alarm that should have and did not: none is defined for "restored DB references missing files".
##  DESIGN CHECK (a design is not a defect, R-370): 07-backup-architecture.md is explicit -
##    "[FACT] What the whole-guest tiers do NOT carry ... mp8 /mnt/felhom-drives ... out of vzdump scope",
##    and the file leg for nextcloud exists at TIER 2 and TIER 3 only (section 6.2 table: Tier-3
##    mandatory = calibre-web, immich, nextcloud, paperless-ngx). Tier 1 carrying no drive-side files is
##    therefore BY DESIGN. What is NOT by design is the page calling tier 1 "DB + Konfig + Adatok" and
##    printing "Adatlemez 65.1 MB" next to it, and a restore reporting plain success while leaving the
##    app inconsistent. Those two are the rows.
  trash re-check at 2026-09-16T11:17:05Z, after the app restarted twice since the restore:
    PROPFIND trash http=207
    entries listed: 1  (1 = only the trash root itself, so the trash is EMPTY to the customer)
