Files

T

admin f3d1ba3062 docs: DIAGNOSE immich offsite restore — findings + ROADMAP R-43/R-44

Viktor deleted 11 immich photos to test offsite restore; both place runs
merged 0 files and flashed success. Two-layered root cause:

- A UI delete means TRASH, not deletion — no file left the disk, so there
  was genuinely nothing missing to restore. The test proved nothing.
- A valid test would also have failed: no offsite path loads a database.
  All three buttons are file-only (offbox_restore.go:171-232, :346-421).
  Files return; the library stays empty. The only DB replay is
  RestoreFromRecoveryUnit, reachable solely from the LOCAL restore panel.

Compounding: the manual push never refreshes dumps (offbox_handlers.go:
203-227) — today's unit dump is from 02:30 and probes to asset:0 / user:0 /
album:0, predating both the admin user and the photos. Had a full restore
loaded it, it would have written an empty DB over the live one, destroying
the trashed rows that were the only surviving recovery path.

Answer to "can a customer trust same-day offsite?" for a DB-indexed app:
no — files come back, content does not.

No product code changed. Photos left in trash (recovery not wanted).
Capability map: customer-restore row stays MISSING by finding, not by
absence of attempt; offsite-restore row flagged scope-contested pending
a ruling on whether CAMPAIGN-6D exercised the DB half.

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

2026-07-19 08:47:34 +02:00

3.6 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

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.

3.6 KiB Raw Blame History