So verhinderst du den Verlust der Immich-Konfiguration bei Upgrades

Verhindern Sie den Verlust der Immich-Konfiguration während Upgrades, indem Sie die Compose-Datei, Umgebungswerte, Datenbank, Upload-Bibliothek und Mount-Definitionen externer Bibliotheken als separate persistente Ressourcen behandeln, die gemeinsam erfasst und wiederhergestellt werden müssen.

Ein Container ist ersetzbar; die ihn umgebende Konfiguration nicht. Ein Upgrade kann den Eindruck erwecken, Immich habe Daten gelöscht, wenn ein relativer Bind-Mount aus einem anderen Projektverzeichnis aufgelöst wird, eine Änderung an der Umgebung den neu erstellten Container nie erreicht oder der neue Stack mit einer leeren Datenbank startet. Erfassen Sie zunächst die aktive Bereitstellung, bewahren Sie versionierte Kopien außerhalb des Hosts auf und testen Sie eine kontrollierte Neuerstellung, bevor Sie auf die Produktionsumgebung umschalten.

Erfassen Sie die aktive Bereitstellung vor jedem Upgrade

Exportieren Sie die effektive Compose-Konfiguration mit redigierten Geheimnissen, notieren Sie Image-Versionen oder -Digests und kopieren Sie die Compose- und Umgebungsdateien in einen versionierten Speicher. Prüfen Sie die Mounts der laufenden Container, statt anzunehmen, dass die Datei in Ihrem Editor die aktuellen Container gestartet hat. Als bestanden gilt die Prüfung, wenn jeder Laufzeitpfad einem bekannten Speicherort auf dem Host zugeordnet ist.

Notieren Sie Pfade externer Bibliotheken, Reverse-Proxy-Einstellungen, die URL für maschinelles Lernen, Datenbankverbindungswerte, Benutzer- und Gruppenidentität, Netzwerknamen sowie Geräte für Hardwarebeschleunigung. Ein fehlender Eintrag führt später zu einer unerklärlichen Abweichung nach dem Upgrade.

Fragen zu Upgrades in der Community zeigen wiederholt, dass Betreiber den Überblick darüber verlieren, welche Compose-Generation oder Umgebungsstruktur gilt. Die hilfreiche Erkenntnis aus einer Diskussion zur Upgrade-Konfiguration besteht darin, die aktuell funktionierende Definition zu bewahren, bevor sie angepasst wird.

Sichern Sie Datenbank, Medien und Bereitstellungsdateien getrennt

Erstellen Sie eine datenbankeigene Sicherung sowie eine Dateisystemsicherung oder einen Snapshot der Upload-Bibliothek und des Bereitstellungsverzeichnisses. Notieren Sie Start- und Abschlusszeiten, Archivgrößen und Prüfsummen. Eine Sicherung, die nur Compose-YAML enthält, kann Container neu erstellen, aber keine Konten, Metadaten, Alben oder Asset-Datensätze wiederherstellen.

Verwenden Sie für die einfachste Konsistenzgrenze eine Sicherung bei angehaltenem Dienst oder koordinieren Sie einen Live-Datenbank-Dump mit einem Speichersnapshot, sodass ihre Beziehung dokumentiert ist. Nehmen Sie externe Bibliotheken auch dann in die Bestandsaufnahme auf, wenn Immich ihre Originaldateien nicht verwaltet, da Pfade und Zugriffsregeln weiterhin den wiederhergestellten Dienst beeinflussen.

Eine von der Community gepflegte Anleitung für Upgrades auf eine Hauptversion betont, wie wichtig die Bewahrung von Datenbank, Medien, Compose- und Umgebungsdaten ist. Betrachten Sie die Reihenfolge als Praxiserfahrung von Betreibern und prüfen Sie jeden Schritt anhand der tatsächlich eingesetzten Version.

Bereiten Sie das Upgrade mit festgelegten Versionen vor

Lesen Sie die Versionshinweise für jede übersprungene Version und aktualisieren Sie die gespeicherte Bereitstellungsdefinition bewusst. Legen Sie die Zielversion fest, laden Sie sie herunter, ohne alte Images zu entfernen, und prüfen Sie die gerenderte Compose-Konfiguration. Unbekannte Variablen, leere Mounts oder gemischte Dienstversionen führen zum Nichtbestehen der Staging-Prüfung.

Wenn die Kapazität es zulässt, stellen Sie die Sicherung in einem isolierten Test-Stack mit anderen Ports und ohne Schreibzugriff auf die Produktion wieder her. Starten Sie ihn mit der Zielversion und prüfen Sie Migrationen, Benutzer, Speicherpfade und Hintergrundaufgaben. Ein erfolgreicher Containerstart allein beweist nicht, dass die ursprüngliche Bibliothek eingebunden ist.

Der zugehörige ZimaSpace-Leitfaden für ein sicheres selbst gehostetes NAS hilft dabei, Bereitstellungsdateien und Sicherungen außerhalb der einzigen Host- und Zugangsdaten-Grenze zu platzieren, die durch ein Upgrade beeinträchtigt werden kann.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Weisen Sie die Persistenz der Konfiguration nach der Neuerstellung nach

Erstellen Sie die Testcontainer vor der Umschaltung anhand der gespeicherten Dateien neu, statt sie lediglich an Ort und Stelle neu zu starten. Prüfen Sie Benutzer, Servereinstellungen, Speichervorlagen, Bibliotheken, Aufgaben, Proxy-Zugriff und die tatsächlich verwendeten Umgebungswerte. Als bestanden gilt die Prüfung, wenn die Konfiguration den Austausch übersteht, weil sie in dokumentierten persistenten Komponenten gespeichert ist.

Laden Sie nach der Umschaltung auf die Produktion ein Test-Asset hoch, führen Sie eine Suche durch, öffnen Sie ein Original und erstellen Sie eine frische Datenbanksicherung. Starten Sie den Stack und den Host neu und wiederholen Sie die Tests. Bewahren Sie die alte Version, die Sicherung und die Bereitstellungsdefinition auf, bis der normale Betrieb während des Beobachtungszeitraums stabil bleibt.

Wenn das Upgrade bereits mit einem leeren Zustand gestartet wurde, stoppen Sie es, bevor die Einrichtung von Benutzern oder neue Uploads widersprüchliche Zustände erzeugen. Binden Sie nur einen verifizierten persistenten Pfad erneut ein oder stellen Sie die Daten in einem sauberen Ziel wieder her. Führen Sie ein Rollback durch, wenn erwartete Benutzer oder Assets fehlen; legen Sie bei weiterhin unklarer Identität eine bereinigte effektive Compose-Konfiguration, Mounts, Versionen und Zeitstempel der Sicherungen vor.