So stellst du Immich nach einem fehlgeschlagenen Container-Update wieder her

Stelle Immich nach einem fehlgeschlagenen Container-Update wieder her, indem du zunächst den aktuellen Zustand unverändert sicherst, jeden Immich-Dienst auf die zuletzt nachweislich funktionierende Version festlegst und Daten nur dann wiederherstellst, wenn ein koordinierter Rollback den Stack nicht starten kann.

Ein Update kann Anwendungscode, Erwartungen an das Datenbankschema, Umgebungsvariablen und Versionen von Begleitdiensten gleichzeitig ändern. Wiederholtes Abrufen von „latest“ oder das Mischen alter und neuer Container erschwert es, die Wiederherstellungsgrenze zu erkennen. Sichere vor jedem Eingriff die Compose-Datei, die Umgebungskonfiguration, Protokolle, Datenbank und Upload-Pfade und entscheide dann zwischen einem Image-Rollback und einer vollständigen Wiederherstellung von Datenbank und Mediathek.

Fehlgeschlagenen Zustand einfrieren und Update-Grenze bestimmen

Stoppe automatische Neustarts und notiere die exakten Images oder Digests für Server-, Machine-Learning-, Datenbank- und Cache-Dienste. Sichere Startprotokolle und Bereitstellungsdateien, bevor du erneut Images abrufst. Bestanden ist dieser Schritt, wenn du benennen kannst, was sich geändert hat; andernfalls sollte die Wiederherstellung pausieren, bis sich die alten Versionen aus der Bereitstellungshistorie oder lokalen Images ermitteln lassen.

Prüfe, ob der Server beendet wird, bevor er eine Verbindung zur Datenbank herstellt, während einer Migration oder erst, nachdem er betriebsbereit geworden ist. Ein Fehler bei der Verbindungsherstellung zu einer Abhängigkeit weist auf eine Reparatur von Netzwerk, Zugangsdaten oder Health-Checks hin; ein Migrationsfehler erhöht das Risiko, nur das App-Image wiederherzustellen, da sich die Datenbank bereits geändert haben kann.

Eine Anleitung zu versionierten Immich-Updates zeigt, warum die Versionsgrenze und die Bereitstellungsdateien wichtig sind. Nutze sie zur Bestandsaufnahme des Übergangs, behandle jedoch deine eigenen Protokolle und Backups als maßgebliche Grundlage für den Rollback.

Zuerst einen vollständigen Rollback auf das zuletzt funktionierende Image versuchen

Lege alle Immich-Anwendungs-Images auf die exakt zuvor funktionierende Version fest, statt nur einen einzelnen Dienst zu ändern. Erstelle die betroffenen Container neu und lasse persistente Volumes unverändert. Wird der Stack wieder betriebsbereit und zeigen die Protokolle keine Schema-Inkompatibilität, ist dieser Rollback mit wenigen Änderungen erfolgreich.

Wenn der alte Server das aktuelle Datenbankschema ablehnt, stoppe. Wechsle nicht abwechselnd zwischen Versionen auf derselben Datenbank und bearbeite Migrationstabellen nicht manuell. Dieser Fehlschlag bedeutet, dass das Update eine Datengrenze überschritten hat und die Wiederherstellung ein Datenbank-Backup erfordert, dessen Zeitstempel zur ausgewählten Anwendungsversion passt.

Ein Bericht zu Immich v1.135.3 dokumentiert einen konkreten Fehler beim Start der Datenbankmigration nach einem Update. Sein abgegrenztes Migrationsbeispiel rechtfertigt eine sorgfältige Prüfung des ersten schwerwiegenden Fehlers; es ist jedoch keine Aufforderung, die Befehle dieses Falls auf eine andere Version zu übertragen.

Datenbank und Medien nur wiederherstellen, wenn ein Rollback keine Wiederherstellung ermöglicht

Erstelle vor der Wiederherstellung eine Sicherheitskopie oder einen Speicher-Snapshot des fehlgeschlagenen Zustands. Richte ein sauberes Wiederherstellungsziel ein, stelle das Datenbank-Backup wieder her und binde anschließend die zugehörige Upload-Mediathek sowie die erforderlichen Bereitstellungsdateien ein. Überschreibe die einzige aktuelle Mediathek nicht einfach mit einer älteren Kopie, nur um Zeitstempel anzugleichen.

Datenbankeinträge und Asset-Dateien müssen dieselbe Sammlung beschreiben. Wenn das Backup vor den letzten Uploads erstellt wurde, bewahre diese neueren Dateien separat zur späteren Zusammenführung auf. Eine Wiederherstellung ist erfolgreich, wenn Migrationen abgeschlossen werden, erwartete Benutzer und Assets erscheinen und stichprobenartig ausgewählte Originale ohne weitverbreitete Fehler wegen fehlender Dateien geöffnet werden können.

Die Immich-Migrationsanleitung von ZimaSpace bietet eine nützliche Bestandsaufnahme für das Verschieben persistenter Komponenten, ohne ein Container-Image mit der Fotomediathek selbst gleichzusetzen.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wiederherstellung validieren, bevor du das Update erneut versuchst

Teste die Anmeldung, das Durchsuchen der Zeitleiste, den Download von Originalen, die Thumbnail-Erstellung, Smart Search, die Gesichtserkennung, einen neuen Upload und ein Datenbank-Backup. Starte die Container und den Host einmal neu. Der Test ist bestanden, wenn nach dem Neustart dieselben Assets und Funktionen verfügbar sind und keine wiederkehrenden Migrations- oder Berechtigungsfehler auftreten.

Bewahre den fehlgeschlagenen und den wiederhergestellten Zustand bis zum Abschluss der Validierung mit klar getrennten Bezeichnungen auf. Wenn die Wiederherstellung von einer älteren Version abhängt, deaktiviere unbeaufsichtigte Image-Abrufe und dokumentiere die festgelegte Version. Versuche das Update erst erneut, nachdem du jede dazwischenliegende Version geprüft und ein frisches, koordiniertes Backup erstellt hast.

Wechsle zum gesicherten Wiederherstellungsziel zurück, wenn ein neuer Upload verschwindet, Originale nicht geöffnet werden können oder Jobs wiederholt abstürzen. Eskaliere mit Quell- und Zielversionen, Image-Digests, dem ersten schwerwiegenden Protokollfehler, dem Zeitstempel des Datenbank-Backups und der Speicherzuordnung; gib die letzte nachweislich funktionierende Kopie niemals auf, solange die Update-Kompatibilität ungeklärt ist.