Files

T

admin 238472b8ed docs: R-43 + R-44 shipped in controller v0.148.0 (live acceptance still pending)

ROADMAP R-43/R-44 → SHIPPED with what actually landed:
  - R-43: ReconstituteFromOffsite — safety dump → stop → files overwritten to
    the snapshot version → start → the snapshot's own dump replayed from the
    SCRATCH unit (the live unit is still never overwritten). Invariants:
    nothing is ever deleted, and the undo is verified on disk before the act.
  - R-44: every run, manual AND nightly, refreshes dumps + units BEFORE the
    capture, so each snapshot is a coherent {DB@T, files@T} pair stamped with
    offsite_run_id + dumps_at. Nightly ordering is now structural rather than a
    coincidence of two scheduler entries at 02:30 and 04:15.

DIAG doc gains a "fixed in v0.148.0" header pointing at both.

Capability map deliberately NOT flipped: the DB half now exists but is PARTIAL,
not PROVEN-LIVE — shipped and deployed with no live acceptance behind it. The
customer-restore row stays MISSING, now blocked only on the evidence run rather
than on missing capability, and R-3 stays DRAFT.

Still open: the 00-capability-map.md:61 ruling — did CAMPAIGN-6D's "immich
end-to-end from offsite alone" exercise the DB half, or only the file half?

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P9Nn14TWGzKoqAJAiVwC2s

2026-07-19 12:27:11 +02:00

4.2 KiB

Raw Blame History

REPORT — DIAGNOSE immich offsite restore (felhom.eu side: docs only)

Written as REPORT-diag-immich-restore.md, not the shared REPORT.md, per the CLAUDE.md convention — REPORT.md is overwritten and currently holds the 2026-07-18 website refresh. No code shipped in this run; findings only.

Date: 2026-07-19 · Box: demo-felhom (felhom-pve guest 9201), controller 0.146.0, immich v3.0.3

CLOSED IN CODE 2026-07-19 — controller v0.148.0. Findings 1 and 2 shipped as R-43 (offsite reconstitution: safety dump → stop → overwrite files → start → replay the snapshot's dump) and R-44 (every run dumps before it captures; manifests carry offsite_run_id + dumps_at). Deployed to demo 9201, healthy. The §9 live acceptance has NOT run, so no capability-map flip: the offsite row is PARTIAL, the customer-restore row stays MISSING, R-3 stays DRAFT. Implementation detail lives in felhom-controller/REPORT.md.

What ran

A diagnosis of "immich offsite restore succeeds but photos do not reappear". No product code was changed: no restore/backup logic, no labels, no flashes, no restic prune/forget, no snapshot or escrow changes.

Outcome

The restore did not fail. It was never invoked on missing data, and could not have worked if it had been.

Viktor deleted the 11 photos in the immich UI to test offsite restore. A UI delete means trash, not deletion — no file left the disk. Both „csak a hiányzó fájlok" runs merged 0 files, correctly, and flashed success. The test proved nothing.
A valid test would also have failed: no offsite path loads a database. All three buttons are file-only. Files would return; the library would stay empty.
The shipped dump is additionally stale by design — from the 02:30 local run, never refreshed before a manual push. Probed: asset: 0, user: 0, album: 0.

Photos: left in trash at Viktor's instruction (recovery not wanted). All 11 files verified present on disk and all 11 rows intact, so an ordinary un-trash recovers them until immich's 30-day auto-purge.

Answer to "can a customer trust same-day offsite?" For a DB-indexed app: no — files come back, content does not. The backup half is honest; the restore half cannot reconstitute the app.

Decisive evidence

updatedAt == deletedAt on all 11 asset rows ⇒ no restore operation touched the DB.
Unit dump immich-postgres.sql, 51 954 452 B, mtime 02:30 CEST ⇒ asset: 0 / user: 0 / album: 0. The 52 MB is entirely immich's shipped geodata reference tables. It predates the admin user (07:56:25) and the photos (07:57).
Latent hazard: had a full restore loaded that dump, it would have written an empty DB over the live one, destroying the trashed rows that were the only surviving recovery path.

Files written

File	Change
`documentation/audits/DIAG-immich-restore-2026-07-19.md`	new — timeline, evidence, source mechanism table, 7 findings
`documentation/backlog/ROADMAP.md`	R-43 (P2-HIGH, offsite restore cannot restore a DB) + R-44 (P2-HIGH, manual push ships unrefreshed dump)
`documentation/architecture/00-capability-map.md`	customer-restore row stays MISSING, gains the finding + a method note for R-3; offsite-restore row flagged scope contested

Needs Viktor

Capability-map ruling (line 61). The offsite-restore row claims PROVEN-LIVE citing "immich end-to-end from offsite alone" (CAMPAIGN-6D). That phrase is contested by this diagnosis. I flagged it rather than downgrading a proven row — did 6D's accept leg exercise the DB half, or only the file half?
Optional real red-proof. Emptying the trash would create genuine data loss and convert the dump-probe inference into a live proof. Offered, not run — irreversible, and the probe already settles it.
Unreconciled: the 704.6 MiB figure. Measured 126 MB total on the library storage. If 704.6 MiB came off a controller Storage page, that gap is its own defect.
Orphaned pre-v3 tree dccc13fe… (~55 MB across upload/thumbs/encoded-video) stranded by the immich 2→3 redeploy — worth a sweep policy for major redeploys.

4.2 KiB Raw Blame History