Record Immich restore test success

docs/IMMICH_RESTORE_TEST.md

@@ -1,6 +1,6 @@
 # Immich Restore Test
 
-Status: **vorbereitet, noch nicht live ausgefuehrt** (2026-05-26)
+Status: **erfolgreich live verifiziert** (2026-05-27)
 Audit-Bezug: `docs/AUDIT_2026-05-25.md` Finding **F-11**
 
 ## Zweck
@@ -22,7 +22,7 @@ Schliesst die Audit-Luecke aus F-11: Immich ist der groesste Datentopf (Familien
 - Extraktion von `local/borg-dumps/latest/immich.dump` aus dem aktuellsten Borg-Archiv
 - Import in eine isolierte `tensorchord/pgvecto-rs:pg14-v0.2.0` Postgres-Instanz mit demselben Digest wie Produktion
 - Start eines isolierten Immich-Server-Containers mit demselben Digest wie Produktion, **ohne** ML-Container und **ohne** Traefik
-- Smoke-Test: Login-Seite erreichbar, `assets`- und `users`-Tabelle lesbar
+- Smoke-Test: Login-Seite erreichbar, `asset`- und `"user"`-Tabelle lesbar
 - Markdown-Report unter `/mnt/user/backups/restore-reports/immich-YYYY-MM-DD.md`
 - Bereinigung von Test-Container und Restore-Lab-Daten nach Erfolg
 
@@ -38,7 +38,7 @@ Schliesst die Audit-Luecke aus F-11: Immich ist der groesste Datentopf (Familien
 
 Der Test deckt **Stufe 4 (kritische Anwendungen)** aus `docs/DISASTER_RECOVERY.md` Phase 4 fuer Immich ab, allerdings nur DB-Ebene und UI-Smoke. Voll-Restore inklusive Foto-Dateien aus Borg ist eigener Folgeschritt; das Skript bereitet die Restore-Lab-Struktur dafuer vor.
 
-## Vor dem ersten echten Lauf
+## Erster Lauf und Preflight
 
 | Pruefung | Verantwortlich | Wo |
 |---|---|---|
@@ -46,15 +46,13 @@ Der Test deckt **Stufe 4 (kritische Anwendungen)** aus `docs/DISASTER_RECOVERY.m
 | Freier Platz unter `/mnt/user/backups/restore-lab/` | erledigt 2026-05-27 | ca. 3.7T frei auf `/mnt/user/backups` |
 | Borg-UI-Container laeuft | Operator | `docker ps | grep borg-ui` |
 | Trockenlauf mit `--what-if` | erledigt 2026-05-27 | Host-Clone auf `c5d231a`, `bash ops/restore-tests/run-restore-checks.sh immich --what-if` erfolgreich |
-| Erster echter Lauf mit `--keep-data` zur Zeitmessung | Operator | `bash ops/restore-tests/immich-restore-test.sh --keep-data` |
+| Erster echter Lauf | erledigt 2026-05-27 | Report `/mnt/user/backups/restore-reports/immich-2026-05-27.md`; Archiv `Tägliche-Sicherung-2026-05-27T04:30:06.778`; HTTP `200`; Assets `11977`; User `1` |
 
 ## Nach dem ersten erfolgreichen Lauf
 
-1. Report unter `/mnt/user/backups/restore-reports/immich-YYYY-MM-DD.md` ueberpruefen.
-2. `docs/RESTORE_MATRIX.md` um den Mini-Restore-Beleg ergaenzen (Datum + Reportpfad), analog zu Paperless 2026-05-07.
-3. `ops/restore-tests/schedule.md` von "Immich spaeter" auf konkreten Quartals-Cron umstellen.
-4. `docs/AUDIT_2026-05-25_TODO.md` F-11 von "offen" auf "erledigt" stellen.
-5. `docs/MIGRATION_LOG.md` mit Mini-Lauf-Befund ergaenzen, ohne Secret-Werte.
+1. Report unter `/mnt/user/backups/restore-reports/immich-2026-05-27.md` liegt vor und ist erfolgreich.
+2. `docs/RESTORE_MATRIX.md`, `ops/restore-tests/schedule.md`, `docs/AUDIT_2026-05-25_TODO.md` und `docs/MIGRATION_LOG.md` wurden nachgezogen.
+3. Quartalsweise Wiederholung einplanen; erster Live-Lauf bleibt bewusst manuell/Operator-kontrolliert, bis mehrere Laeufe stabil waren.
 
 ## Schutzregeln
 
@@ -67,15 +65,14 @@ Der Test deckt **Stufe 4 (kritische Anwendungen)** aus `docs/DISASTER_RECOVERY.m
 
 ## Risiken (aus `ops/restore-tests/immich-plan.md`)
 
-- Dump-Groesse und `pg_restore`-Dauer sind aktuell nicht gemessen.
+- Dump-Groesse und erster `pg_restore`-Lauf sind gemessen: `immich.dump` 66M, echter Smoke-Test erfolgreich am 2026-05-27.
 - pgvecto-rs Extension-Mismatch bei Image-Drift moeglich; Compose pinnt denselben Digest wie Produktion.
+- Immich v2 meldet pgvecto-rs als deprecated; VectorChord-Migration ist ein kuenftiger Immich-Upgrade-Punkt, nicht Teil dieses Restore-Tests.
 - Immich-Server-Migrations koennen Startup nach Restore verzoegern; Skript pollt 120 s.
-- Bei Schema-Drift (z. B. nach Major-Update) brechen einzelne DB-Queries; das Skript faengt das tolerant ab und schreibt `n/a` in den Report.
+- Bei Schema-Drift (z. B. nach Major-Update) koennen einzelne DB-Queries abweichen; das Skript versucht Immich-v2-Singular-Tabellen und aeltere Plural-Fallbacks.
 
 ## Naechste Operator-Schritte
 
-1. Skript mit `--what-if` ausfuehren und den Plan-Output gegenpruefen.
-2. Dump-Groesse und freien Platz pruefen.
-3. Ersten echten Lauf mit `--keep-data` ausfuehren, Dauer messen.
-4. Bei Erfolg: Restore-Matrix, Schedule, Audit-TODO und Migration-Log nachziehen.
-5. Bei Fehler: Restore-Lab nicht selbst manuell bereinigen, sondern den Trap-Cleanup laufen lassen und ggf. Logs sichern, bevor erneut gestartet wird.
+1. Quartalsweise Wiederholung nach `ops/restore-tests/schedule.md` einplanen.
+2. Bei zukuenftigem Immich-Major-Upgrade den Restore-Test unmittelbar danach einmal manuell ausfuehren.
+3. Voll-Restore inklusive Foto-Dateien bleibt ein eigener, deutlich groesserer DR-Drill.