Eine Checkliste vor dem Upgrade für Jellyfin-Container und Abhängigkeiten

Bewahren Sie vor dem Upgrade eines Jellyfin-Containers beide Seiten der Bereitstellung: den persistenten Jellyfin-Zustand und die exakte Containerdefinition, die den Zugriff darauf ermöglicht. Ein neues Image ist schnell geladen; die Wiederherstellung einer migrierten Datenbank, eines geänderten Mounts oder einer vergessenen Gerätezuordnung ist es nicht.

Verwenden Sie die Checkliste in Abhängigkeitsreihenfolge. Stellen Sie zunächst sicher, dass Sie die Daten wiederherstellen können, dokumentieren Sie dann das aktuelle Image und die Laufzeiteinstellungen, lesen Sie anschließend den Upgrade-Pfad und ersetzen Sie erst danach das Image. Testen Sie anschließend dieselben Bibliotheken, Benutzer, Wiedergabemodi, geplanten Aufgaben und das Neustartverhalten, bevor Sie die Rollback-Kopie löschen.

Das zuletzt funktionierende Image und die Containerdefinition dokumentieren

Speichern Sie den aktuellen Jellyfin-Image-Tag und, wenn möglich, auch dessen Digest. Exportieren oder kopieren Sie die Compose-Datei oder App-Definition mit Ports, Netzwerken, Mounts, Umgebungswerten, Neustartrichtlinie, Benutzerzuordnung, zusätzlichen Gruppen, GPU-Geräten und etwaigen Beziehungen zu einem Reverse-Proxy.

Die offizielle Jellyfin-Container-Dokumentation unterscheidet zwischen sich bewegenden Tags wie latest und expliziten Major-, Minor- und Patch-Tags. Verhalten von Jellyfin-Image-Tags Ein Rollback ist einfacher, wenn Sie die exakt funktionierende Version kennen, statt sich nur daran zu erinnern, dass „latest gestern funktioniert hat“.

Entfernen Sie das alte Image nicht und löschen Sie die gespeicherte Definition erst, wenn die neue Version das vollständige Validierungsfenster bestanden hat. Falls das Upgrade fehlschlägt, bevor persistente Daten verändert wurden, bieten das aufbewahrte Image und die Definition den schonendsten Wiederherstellungspfad.

Ein wiederherstellbares Backup des Jellyfin-Zustands erstellen

Sichern Sie die Jellyfin-Daten- und Konfigurationsverzeichnisse, bevor sich das Image ändert. Das Backup muss sich außerhalb des Live-Anwendungspfads befinden und unabhängig lesbar sein; eine zweite Kopie oder ein Snapshot auf demselben Datensatz ist nur dann sinnvoll, wenn Sie verstehen, vor welchem Ausfall er schützt.

Die Jellyfin-Dokumentation zu Backups warnt, dass nach Upgrades eine Wiederherstellung der Daten erforderlich sein kann, da es nach angewendeten Migrationen keinen allgemeinen Downgrade-Mechanismus gibt. Sie dokumentiert außerdem integrierte Backups und die erforderliche saubere Beendigung für manuelle Dateikopien. Hinweise zu Jellyfin-Backup und -Wiederherstellung

Für einen Container-Workflow wird dasselbe Prinzip durch den Rollback-Punkt-Workflow vor dem Update von ZimaSpace abgedeckt. Halten Sie hier an, wenn Sie die persistenten Pfade nicht identifizieren oder den Inhalt des Backups nicht überprüfen können.

Mounts, UID/GID und Hardwareabhängigkeiten erfassen

Listen Sie jeden Bind-Mount und jedes benannte Volume auf und vermerken Sie, ob es schreibgeschützt oder beschreibbar ist. Dokumentieren Sie die Laufzeit-UID/GID, Gruppenmitgliedschaften und die Eigentumsverhältnisse der Jellyfin-eigenen Datenverzeichnisse. Erfassen Sie außerdem GPU- oder Rendergeräte-Zuordnungen, falls Hardwarebeschleunigung aktiviert ist.

Der Container-Leitfaden von Jellyfin zeigt, dass Medien, Konfiguration und Cache getrennt gemountet werden und der Container unter einer angegebenen UID/GID ausgeführt werden kann. persistente Pfade und Benutzerzuordnung Diese Werte sind Abhängigkeiten und keine bloße Dekoration: Ein neu erstellter Container kann erfolgreich starten, während er ein leeres Konfigurationsverzeichnis sieht oder die Berechtigung für ein Gerät verliert.

Vergleichen Sie die gespeicherte Definition mit dem tatsächlich laufenden Container, nicht nur mit einer Vorlage, die Ihrer Meinung nach aktuell ist. Falls die Laufzeit manuelle Änderungen enthält, die in Compose oder der NAS-App-Definition fehlen, beheben Sie diese Abweichung vor dem Upgrade, damit die alte Bereitstellung reproduzierbar ist.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Den unterstützten Upgrade-Pfad und Plugin-Risiken prüfen

Lesen Sie die Versionshinweise für jede Major-Grenze zwischen der aktuellen und der Zielversion. Achten Sie auf erforderliche Zwischenversionen, Datenbankmigrationen, geänderte Konfigurationen, Plugin-Kompatibilität, FFmpeg-Anforderungen oder langwierige Arbeiten beim Start.

Die Upgrade-Dokumentation von Jellyfin betont wiederholt Backups und erklärt, warum Schemaänderungen einen einfachen Downgrade unmöglich machen können. Upgrade- und Downgrade-Grenzen Die Versionshinweise zu Major-Releases können versionsspezifische Voraussetzungen hinzufügen. Schließen Sie daher nicht allein daraus, dass ein Container-Image existiert, dass ein direkter Sprung sicher ist.

Wenn ein Plugin unverzichtbar ist, bestätigen Sie vor dem Server-Upgrade, dass eine kompatible Version verfügbar ist. Wenn ein Plugin optional ist und in der Vergangenheit den Start blockiert hat, dokumentieren Sie seine aktuelle Version und seien Sie darauf vorbereitet, nur dieses Plugin zu deaktivieren, falls die neuen Serverprotokolle es als Fehlerquelle identifizieren.

Das Upgrade durchführen, ohne die Zustandsgrenze zu verändern

Beenden Sie Jellyfin sauber, laden Sie das gewünschte Image und erstellen Sie nur den Jellyfin-Dienst mit denselben geprüften persistenten Pfaden und Laufzeitabhängigkeiten neu. Kombinieren Sie das Upgrade nicht mit einer Speichermigration, einer Neugestaltung von UID/GID, einer Überarbeitung des Reverse-Proxys und einer GPU-Neukonfiguration, es sei denn, diese Änderungen sind der eigentliche Zweck der Wartung.

Beobachten Sie das Protokoll des ersten Starts. Eine Migration kann bei einer großen Bibliothek durchaus Zeit benötigen, während eine sofortige Meldung wie „permission denied“, eine leere Datenbank, ein fehlender Pfad oder ein inkompatibles Schema auf einen anderen Fehlerzweig hinweist. Starten Sie eine Migration nicht wiederholt neu, nur weil die Benutzeroberfläche nicht sofort verfügbar ist.

Wenn der Container als frischer Server geöffnet wird, stoppen Sie ihn, bevor Sie irgendetwas konfigurieren. Dieses Symptom bedeutet meist, dass der neue Dienst auf den falschen persistenten Zustand verweist. Korrigieren Sie zuerst die Mount-Zuordnung. Das Konfigurieren einer neuen leeren Instanz kann neue Dateien erzeugen, die den Wiederherstellungspfad verdecken.

Die neue Version validieren, bevor Rollback-Ressourcen entfernt werden

Überprüfen Sie die Identität des ursprünglichen Servers, Benutzer, Bibliotheken, Metadaten und wichtigen Einstellungen. Spielen Sie ein Element im Direct-Play-Modus und einen repräsentativen Transcode ab und führen Sie anschließend eine für Ihre Einrichtung wichtige geplante Aufgabe aus oder beobachten Sie deren Ausführung. Prüfen Sie die Protokolle auf wiederkehrende Migrations-, Datenbank-, Berechtigungs- und FFmpeg-Fehler.

Starten Sie den Container nach der ersten erfolgreichen Sitzung einmal neu. Die neue Version ist erst vollständig validiert, wenn sie dieselben Daten und Geräte nach einer sauberen Neuerstellung oder einem Neustart erneut öffnen kann. Dadurch werden versehentliche Abhängigkeiten von einem temporären Mount oder Laufzeitstatus erkannt.

Bewahren Sie das Backup vor dem Upgrade, die Referenz des vorherigen Images und die gespeicherte Definition auf, bis der Server sein normales Auslastungsfenster bestanden hat. Falls nach einer Datenbankmigration ein Rollback erforderlich ist, befolgen Sie die dokumentierten Wiederherstellungsgrenzen von Jellyfin, anstatt ein älteres Image auf einen bereits migrierten Zustand zu verweisen.