Warum verliert Immich nach der Neuerstellung des Stacks den Zugriff auf persistente Daten?

Wenn Immich nach der Neuerstellung des Stacks leer aussieht oder seine Bibliothek nicht lesen kann, gehen Sie zunächst davon aus, dass die alten persistenten Daten getrennt oder nicht lesbar sind, bevor Sie annehmen, dass sie gelöscht wurden.

Durch das Neuerstellen von Containern können sich die Compose-Projektidentität, die Quelle eines Bind-Mounts, die Zuordnung eines benannten Volumes, der Zeitpunkt der Netzwerkfreigabe oder die UID/GID ändern, mit der die Daten gelesen werden. Stoppen Sie die frisch wirkende Instanz, bevor sie umfangreich neue Zustände schreibt, suchen Sie die alten Datenbank- und Medienpfade auf dem Host und vergleichen Sie den neu erstellten Stack mit der letzten funktionierenden Zuordnung. Ziel ist es, zuerst den vorhandenen Zustand wieder anzubinden; stellen Sie erst dann aus einem Backup wieder her, wenn Sie nachgewiesen haben, dass dieser Zustand tatsächlich fehlt oder beschädigt ist.

Die frische Instanz stoppen und nachweisen, dass die alten Daten noch vorhanden sind

Ein Einrichtungsassistent, eine leere Zeitleiste oder eine fehlende externe Bibliothek unmittelbar nach der Neuerstellung ist ein Warnsignal für ein Persistenzproblem. Stoppen Sie Immich und überprüfen Sie die datenbank- und medienbezogenen Speicherorte auf dem Host, bevor Sie neue Dateien hochladen oder eine neue leere Konfiguration übernehmen. Neue Schreibvorgänge können spätere Pfadvergleiche erschweren.

Prüfen Sie die alten Verzeichnisse auf die erwartete Anzahl von Dateien, Änderungsdaten, Datenbankdateien oder Dumps sowie repräsentative Originalbilder. Sind die Daten auf dem Host vorhanden, handelt es sich eher um ein Zugriffs- oder Zuordnungsproblem als um ein Verschwinden der Daten. Erstellen Sie einen schreibgeschützten Snapshot oder ein Backup dieses Zustands, bevor Sie Besitzrechte ändern oder Verzeichnisse verschieben.

Wenn die alten Daten an den erwarteten Pfaden nicht gefunden werden können, durchsuchen Sie den Speicherpool und das Docker-Volume-Inventar, bevor Sie etwas löschen. Die Entscheidungsgrenze ist binär: Der vorhandene Zustand wurde gefunden und geschützt, oder er ist tatsächlich nicht verfügbar und der Wiederherstellungspfad führt zu einem bekannten funktionierenden Backup statt zu einer Reparatur der Mounts.

Die neu erstellten Mounts mit dem vorherigen Stack vergleichen

Überprüfen Sie die tatsächlich wirksamen Mounts in den neu erstellten Immich-Server- und Datenbankcontainern, nicht nur den Compose-Text, an dessen Bearbeitung Sie sich erinnern. Ein relativer Bind-Pfad kann von einem anderen Projektverzeichnis aus aufgelöst werden, und ein umbenanntes Compose-Projekt kann ein neues benanntes Volume anbinden, während das alte weiterhin vorhanden, aber ungenutzt ist.

Ein fehlgeschlagener, geänderter oder fehlender Mount kann innerhalb eines Containers ein leeres Verzeichnis anzeigen, obwohl die erwarteten Daten weiterhin an anderer Stelle auf dem Host vorhanden sind. Verwenden Sie Prüfungen für Docker-Volume-Mounts, um für jeden persistenten Immich-Pfad Source, Destination, Mount-Typ und die Identität des benannten Volumes zu vergleichen. Eine Abweichung an dieser Stelle erklärt direkt, warum die Instanz wie frisch eingerichtet aussieht.

Korrigieren Sie ausschließlich die fehlerhafte Mount-Zuordnung und erstellen oder starten Sie anschließend den Container, ohne Volumes zu entfernen. Wenn die erwarteten Dateien nach der Änderung am selben Containerpfad erscheinen, lassen Sie die Daten an ihrem bisherigen Ort. Wenn die Mount-Liste korrekt ist, der Zugriff aber weiterhin fehlschlägt, behalten Sie die Zuordnung bei und prüfen Sie die Verfügbarkeit des Host-Speichers sowie die Berechtigungen, anstatt ein weiteres Volume zu erstellen.

Überprüfen, ob der externe Speicher vor dem Start von Immich eingebunden war

Wenn die Immich-Daten auf einem HDD-Pool, einer NAS-Freigabe, einer Merger-Schicht oder einem anderen externen Mount liegen, bestätigen Sie, dass dieser Speicher auf dem Host tatsächlich eingebunden ist, bevor Docker den Stack startet. Ein Pfad wie /mnt/photos kann weiterhin als gewöhnliches lokales Verzeichnis existieren, obwohl das eigentliche Gerät fehlt.

Persistente Docker-Daten bleiben beim Ersetzen von Containern nur dann erhalten, wenn das vorgesehene Volume oder der Bind-Mount korrekt erneut angebunden wird. Das zugrunde liegende Persistenzmodell von Docker-Volumes lässt eine fehlende Host-Festplatte oder Netzwerkfreigabe nicht automatisch erscheinen. Überprüfen Sie daher das Speichergerät und eine bekannte Datei auf dem Host, bevor Sie denselben Pfad innerhalb von Immich testen.

Wenn Sie feststellen, dass Fallback-Dateien in den leeren Mountpoint geschrieben wurden, während der eigentliche Speicher nicht verfügbar war, stoppen Sie Immich, bevor Sie das Gerät darüber einbinden. Stimmen Sie diese Dateien separat ab, fügen Sie eine Startabhängigkeit oder einen Healthcheck für den Storage-Mount hinzu und starten Sie erst danach den Stack neu. Wenn der Host-Speicher stabil ist und der Containerpfad weiterhin nicht lesbar ist, fahren Sie mit dem Berechtigungszweig fort.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

UID, GID und Verzeichnisberechtigungen prüfen, ohne alles neu zu schreiben

Ein neu erstellter Stack kann einen Dienst mit einer anderen numerischen Identität, einem anderen User-Namespace oder einem anderen Sicherheitskontext als der alte ausführen. Das Ergebnis unterscheidet sich von einem fehlenden Mount: Der Pfad existiert und die Dateien sind vom Host aus sichtbar, aber die Immich-Protokolle zeigen Berechtigungsfehler oder Immich kann erwartete Dateien nicht erstellen.

Vergleichen Sie den numerischen Besitzer und die Modusbits der betroffenen Host-Verzeichnisse mit der Benutzeridentität innerhalb des neu erstellten Containers. Testen Sie zunächst einen harmlosen Lesezugriff und anschließend einen reversiblen Schreibvorgang an einem temporären Ort unter demselben Mount. Vermeiden Sie eine rekursive Änderung der Besitzrechte im gesamten Fotoarchiv, bis Sie wissen, welcher Dienst Schreibzugriff benötigt und welche Originaldateien unverändert bleiben sollen.

Beheben Sie die kleinste Verzeichnis- oder Identitätsabweichung, die den Fehler erklärt, starten Sie einmal neu und prüfen Sie die Protokolle erneut. Wenn der Zugriff trotz übereinstimmender Mounts und Berechtigungen weiterhin fehlschlägt, nehmen Sie keine weiteren Änderungen am Dateisystem vor und untersuchen Sie die Datenbankverbindung, die Umgebungsvariablen-Ersetzung oder die Sicherheitsebene, die sich durch die Neuerstellung geändert hat.

Den ursprünglichen Zustand wieder anbinden und eine weitere Neuerstellung überprüfen

Sobald die alten Datenbank- und Medienpfade angebunden und lesbar sind, starten Sie Immich und suchen Sie nach den alten Benutzern, Alben, Personen und repräsentativen Assets. Erklären Sie die Reparatur nicht für abgeschlossen, nur weil die Startseite geladen wird. Überprüfen Sie, dass die Anwendung den ursprünglichen Zustand liest und nicht eine neu initialisierte Datenbank daneben verwendet.

Die entscheidende Grenze ist, dass Container kurzlebig sein können, während der Anwendungszustand auf stabilem Speicher außerhalb des Container-Lebenszyklus verbleiben muss. Dokumentieren Sie die korrigierten Mount-Namen und Host-Pfade und verwenden Sie persistente Speicherrollen eines Dateiservers, damit der nächste Stack-Neuaufbau wieder mit denselben Daten verbunden wird.

Erstellen Sie den Stack abschließend noch einmal unter kontrollierten Bedingungen und wiederholen Sie die ursprünglichen Prüfungen. Die Lösung ist erst dann bewiesen, wenn dieselbe Datenbank und dieselben Medien nach der Neuerstellung und nach einem Neustart des Hosts wieder erscheinen. Wenn der alte Zustand erneut verschwindet oder die Datenbank eine Beschädigung statt eines Zugriffsfehlers meldet, stellen Sie die geschützte Kopie wieder her und wechseln Sie zur Datenbank- bzw. Backup-Wiederherstellung, anstatt weitere Mount-Experimente durchzuführen.