Die Quelldaten waren nicht offensichtlich verloren. Nach dem Zurücksetzen von ZimaOS war das RAID6 weiterhin vorhanden, und Verzeichnisse wie upload, pgdata, thumbs, profileund encoded-video waren weiterhin vorhanden. Das Problem bestand darin, dass der neu installierte Immich-Stack nicht so mit dem alten Datenbank-/Bibliotheksstatus verbunden war, dass der vorherige Fotokatalog wiederhergestellt wurde.
Der sicherste Ratschlag der Quelle lautete: Die alten upload- und pgdata-Ordner vorerst weder löschen noch verschieben. Immich erstellt seinen vollständigen Katalog nicht einfach neu, nur weil es Bilddateien auf dem Datenträger erkennt. Die Datenbank enthält Dateipfade, Benutzer, Alben, Metadaten und den Anwendungsstatus. Die aktuelle Immich-v3-Dokumentation macht diese Beziehung ausdrücklich deutlich und empfiehlt, sowohl die Asset-Dateien als auch die Datenbank zu sichern.
Zuerst den tatsächlichen RAID-Einhängepfad bestätigen
Die Quelle verwendete:
ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)und fand:
/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/uploadDamit war festgestellt, dass die alten Immich-Ordner auf dem RAID noch vorhanden waren.
/media/ZimaOS-HD → /DATA bewies nicht, dass Immich das Betriebssystemlaufwerk verwendete.
Der Benutzer war beunruhigt durch:
/media/ZimaOS-HD -> /DATADie Community erklärte jedoch korrekt, dass dies eine ZimaOS-Einbindungs-/Symlink-Beziehung ist. Ihre Existenz sagt nicht aus, welche Host-Pfade die Immich-Container tatsächlich verwenden.
Die effektiven Docker-Einbindungen prüfen
Der Beitrag empfahl, Folgendes zu prüfen:
docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'Das ist zuverlässiger, als davon auszugehen, dass ein Screenshot oder eine alte Erinnerung die Konfiguration des laufenden Containers korrekt wiedergibt.
Die alten pgdata-Daten sind genauso wichtig wie die alten Fotodateien.
Wenn die Neuinstallation eine völlig neue Datenbank statt der alten initialisiert hat, können die Dateien weiterhin vorhanden sein, während Immich leer erscheint.
Aktuelles Immich verwendet UPLOAD_LOCATION und DB_DATA_LOCATION
Im aktuellen Immich-v3-Compose werden der Asset-Speicherort auf dem Host und der Postgres-Speicherort mithilfe von UPLOAD_LOCATION und DB_DATA_LOCATION. Das Upstream-Projekt weist ausdrücklich darauf hin, dass Netzwerkfreigaben für den Datenbankpfad nicht unterstützt werden.
Verwende das aktuelle Immich-Speichermodell.
Ein Datenbank-Backup ist sicherer, als ein aktives altes pgdata-Verzeichnis versionsübergreifend erneut anzubinden
Die Quelle verwendete Immich v2.7.2. Die aktuelle Immich-Version ist v3. Bei einer Wiederherstellung zwischen Versionen ist der Datenbank-Sicherungs- und -Wiederherstellungsprozess des Upstream-Projekts sicherer, als davon auszugehen, dass ein altes Postgres-Datenverzeichnis einfach an ein neueres Datenbank-Image angehängt werden kann.
Siehe den aktuellen Immich-Sicherungs- und Wiederherstellungsprozess.
Die internen Asset-Ordner von Immich nicht manuell neu anordnen
Die aktuelle Immich-Dokumentation warnt, dass Ordner wie library, upload, thumbs, profileund encoded-video werden von der Anwendung verwaltet. Das Verschieben oder Löschen einzelner Dateien hinter Immich kann dazu führen, dass Assets fehlen oder nicht mehr erfasst sind.
Der Quellnutzer bestätigte keine erfolgreiche Wiederherstellung
Community-Mitglieder schlugen mehrere Zuordnungsansätze vor, darunter einen einzigen übergeordneten Mount. jerlo legte das Problem letztlich jedoch beiseite und begann auf einem anderen System von vorn. Daher bestätigt das Forum keinen bestimmten Pfad-Mapping-Ansatz als endgültige Lösung.
Immich bevorzugt derzeit einen verwalteten Upload-Stammordner, statt jeden Unterordner manuell zuzuordnen
In den Quell-Screenshots wurden manuell zugeordnet upload, thumbs, profile, library, encoded-video, sowie die Sicherungen einzeln. Das aktuelle Upstream-Compose konzentriert sich stattdessen auf die Host-Konfiguration von UPLOAD_LOCATION, wobei Immich seine internen Unterverzeichnisse unterhalb dieses Stammverzeichnisses verwaltet.
Beim Neuaufbau mit einer neueren Immich-Version sollte das aktuelle Compose-/Speicherlayout verwendet werden, statt eine historische Gruppe von Unterverzeichniszuordnungen nachzubilden, sofern das Paket dies nicht ausdrücklich erfordert.
Den PostgreSQL-Datenpfad auf unterstütztem lokalem Speicher belassen
Die aktuelle Immich-Dokumentation sagt ausdrücklich, dass Netzwerkfreigaben nicht unterstützt werden für DB_DATA_LOCATION. Ein lokal eingebundenes RAID-/Speicherdateisystem kann geeignet sein, aber ein per SMB/NFS eingebundenes Datenbankverzeichnis ist kein unterstützter Datenbankpfad.
Eine vollständige Immich-Wiederherstellung benötigt sowohl Assets als auch die Datenbank
Die aktuelle Immich-Dokumentation zur Datensicherung besagt, dass Datenbanksicherungen Metadaten und Benutzerinformationen enthalten, nicht jedoch die Foto-/Video-Assets. Der Asset-Baum muss separat gesichert und zusammen mit einer kompatiblen Datenbanksicherung wiederhergestellt werden.
Das erklärt, warum „die Upload-Dateien sind noch vorhanden“ im Ausgangsfall zwar beruhigend, aber nicht ausreichend war.
Ein altes aktives pgdata-Verzeichnis nicht ohne Weiteres an eine andere PostgreSQL-/Image-Version anhängen
Ein unbearbeitetes PostgreSQL-Datenverzeichnis ist versionsabhängig. Wenn die alte Umgebung und das neue Paket unterschiedliche PostgreSQL- oder Immich-Versionen verwenden, sollten Sie einen unterstützten Datenbank-Dump und eine Wiederherstellung oder einen dokumentierten Migrationsweg bevorzugen. Erstellen Sie eine bytegenaue Sicherung des alten pgdata vor dem Experimentieren.
FAQ zur Immich-Wiederherstellung
Hat das Zurücksetzen von ZimaOS die Fotoordner des Quell-RAID6 gelöscht?
Nein. Der Benutzer sagte, dass das RAID und die vorhandenen Verzeichnisse/Dateien intakt geblieben sind.
Wird das Zuordnen allein der alten Fotodateien die Immich-Bibliothek wiederherstellen?
Nicht unbedingt. Immich benötigt auch den entsprechenden Datenbank-/Katalogstatus.
Was sollte vor dem Experimentieren geschützt werden?
Der vollständige Speicherort der Assets sowie die Datenbank oder eine verifizierte Datenbanksicherung.
