So führen Sie ein sicheres Rollback von Immich nach einer inkompatiblen Version durch

Führen Sie für Immich nur dann ein Rollback durch, wenn Sie zunächst den aktuellen Zustand sichern und feststellen, ob die neuere Version die Datenbank oder Konfiguration so verändert hat, dass das ältere Image sie nicht lesen kann.

Ein Container-Image ist austauschbar, sein persistenter Zustand wurde möglicherweise jedoch bereits migriert. Wenn ein Upgrade fehlschlägt, stoppen Sie automatische Updates und neue Schreibvorgänge, dokumentieren Sie beide Versionen, sichern Sie die aktuelle Datenbank und die Mediendateien und entscheiden Sie dann zwischen einem einfachen Image-Rollback und der Wiederherstellung des Wiederherstellungspunkts vor dem Upgrade.

Fehlgeschlagenes Upgrade einfrieren, bevor sich der Zustand weiter verändert

Deaktivieren Sie automatische Image-Updates und verhindern Sie, dass Clients neue Fotos hinzufügen, während Sie Beweise sammeln. Notieren Sie die exakten alten und neuen Immich-Image-Versionen oder -Digests, die PostgreSQL-Version, Compose- und Umgebungsdateien, die Einhängepfade sowie den ersten Start- oder Migrationsfehler.

Der ZimaSpace-Leitfaden zu Rollback-Grenzen bei Container-Images macht den entscheidenden Unterschied deutlich: Persistente Volumes bleiben beim Austausch eines Images erhalten, aber das ist nur dann sicher, wenn die ältere Anwendung weiterhin mit dem darin enthaltenen Zustand kompatibel ist.

Erstellen Sie eine datenbanknative Sicherung des aktuellen fehlerhaften Zustands, sofern die Datenbank gelesen werden kann, und bewahren Sie die Sicherung vor dem Upgrade separat auf. Überschreiben Sie keine der beiden Sicherungen durch wiederholte Experimente. Die aktuelle Kopie wird möglicherweise später benötigt, um wieder auf einen neueren Stand zu gelangen, selbst wenn das unmittelbare Ziel die Rückkehr zur älteren Version ist.

Feststellen, ob die Version eine Datenbankmigrationsgrenze überschritten hat

Prüfen Sie den ersten Fehler nach dem Upgrade und stellen Sie fest, ob er vor oder während der Datenbankmigration, nach der Migration beim Start der Anwendung oder erst bei einem bestimmten Benutzerablauf auftritt. Dieser Zeitpunkt verändert den Rollback-Plan, da ein älteres Image möglicherweise ein von der neueren Version bereits geändertes Schema nicht versteht.

Ein aktueller Immich-Bericht, in dem der Dienst nach einem Upgrade-Pfad fehlschlug, zeigt, warum nicht unterstützte oder übersprungene Migrationspfade einen einfachen Versionswechsel unzuverlässig machen können. Betrachten Sie den Beitrag als Fallstudie und überprüfen Sie die genaue Migrationsabfolge für Ihre Versionen.

Wenn die neuere Anwendung die Datenbank nie berührt hat und der Fehler auf die Kompatibilität von Image oder Laufzeitumgebung beschränkt ist, kann ein Rollback auf ein festgelegtes Image ausreichen. Wenn Migrationen abgeschlossen wurden, sollten Sie davon ausgehen, dass die Datenbanksicherung vor dem Upgrade der sicherere Partner für das alte Image ist, sofern Sie keine eindeutigen Kompatibilitätsnachweise haben.

Passende Datenbank und Laufzeitumgebung wiederherstellen, statt Epochen zu vermischen

Erstellen Sie das Rollback-Ziel aus der letzten bekanntermaßen funktionierenden Anwendungsversion, ihrer kompatiblen Bereitstellungskonfiguration und dem Datenbank-Wiederherstellungspunkt vor der inkompatiblen Änderung. Lassen Sie den Medienbestand unverändert, sofern die Version die Mediendateien nicht nachweislich auf dokumentierte Weise geändert hat; kopieren Sie nicht mehrere Terabyte erneut, nur weil sich das Anwendungs-Image geändert hat.

Die Diskussion zum Datenbank-Rollback in der Planung datenbankkompatibler Rollbacks erläutert die allgemeine Gefahr, ältere Software gegen ein Schema einzusetzen, das sie nicht mehr versteht. Dieses Prinzip ist wichtiger als die Frage, ob der Container selbst erfolgreich startet.

Starten Sie die Rollback-Instanz isoliert, damit mobile Clients und geplante Aufgaben bis zum Abschluss der Validierung keine Schreibvorgänge ausführen können. Wenn die alte Version sofort Schemafehler meldet, halten Sie an. Erzwingen Sie keine manuellen Rückwärtsmigrationen auf der einzigen Datenbankkopie, es sei denn, Sie verfügen über ein getestetes, versionsspezifisches Wiederherstellungsverfahren.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Exaktes bekanntermaßen funktionierendes Image festlegen und Konfiguration reproduzieren

Verwenden Sie eine bestimmte Version oder eine unveränderliche Image-Referenz statt eines beweglichen Tags. Stellen Sie die passende Umgebung, Dienstabhängigkeiten, Gerätezuordnungen, Netzwerke, Ports und das Reverse-Proxy-Ziel der letzten bekanntermaßen funktionierenden Bereitstellung wieder her. Ein Rollback, das unbemerkt mehrere Infrastrukturebenen verändert, erzeugt einen zweiten Vorfall.

Bewahren Sie das fehlerhafte neuere Image und die zugehörige Konfiguration zusammen mit den Rollback-Notizen auf. So bleibt eine kontrollierte Wiederherstellung auf die neuere Version möglich, sobald die Inkompatibilität verstanden ist. Wenn Sie alle neuen Artefakte sofort entfernen, wird es schwieriger, die fehlerhaften und funktionierenden Zustände zu vergleichen oder das Upgrade in einer Testumgebung zu reproduzieren.

Wenn der ältere Dienst mit dem wiederhergestellten Zustand startet, prüfen Sie die Protokolle, bevor Sie Clients aktivieren. Stellen Sie sicher, dass kein unerwarteter Migrationsversuch, keine Initialisierung einer Neuinstallation, kein fehlender Speichereinbindungspunkt und keine Änderung von Berechtigungen auftritt. Eine Anmeldeseite allein beweist nicht, dass das Rollback die vorgesehenen Daten verwendet.

Alte Version unter dem ursprünglichen Auslöser validieren und einen Weg nach vorn offenhalten

Testen Sie repräsentative Benutzer, alte und aktuelle Dateien, Alben, Freigaben, die Suche, einen kontrollierten neuen Upload, Hintergrundaufgaben, die Erstellung einer Datenbanksicherung und die Reverse-Proxy-Route. Starten Sie den Stack einmal neu und bestätigen Sie, dass dieselben Einbindungen und dieselbe Datenbank ohne manuelle Eingriffe wieder verfügbar sind.

Halten Sie neue Uploads pausiert, bis diese Prüfungen bestanden sind, öffnen Sie anschließend den Zugriff wieder und beobachten Sie das normale Lastfenster. Bewahren Sie sowohl die Sicherung vor dem Upgrade als auch die Sicherung des fehlerhaften neueren Zustands auf, damit Sie das Upgrade später in einer isolierten Kopie erneut versuchen können, sobald die Kompatibilitätsprobleme verstanden sind.

Das Rollback ist fehlgeschlagen, wenn die ältere Version eine Schema-Inkompatibilität meldet, bekannte Daten fehlen oder Schreibvorgänge an einem unerwarteten Pfad landen. Halten Sie an und stellen Sie den aufbewahrten Wiederherstellungspunkt erneut her, statt weitere Reparaturen darauf aufzubauen. Eskalieren Sie den Fall mit den exakten Versionen, Migrationsprotokollen, Zeitstempeln der Datenbanksicherungen, dem Compose-Diff und dem ersten fehlgeschlagenen Validierungsschritt.