Eine Checkliste vor dem Upgrade von Jellyfin-Containern und Abhängigkeiten

Sichere vor dem Upgrade eines Jellyfin-Containers beide Seiten der Bereitstellung: den persistenten Jellyfin-Zustand und die genaue Container-Definition, die weiß, wie sie darauf zugreift. Ein neues Image lässt sich leicht herunterladen. Eine migrierte Datenbank, einen geänderten Mount oder eine vergessene Gerätezuordnung wiederherzustellen, ist es nicht.

Arbeite die Checkliste in der Reihenfolge der Abhängigkeiten ab. Stelle zuerst sicher, dass du die Daten wiederherstellen kannst, dokumentiere dann das aktuelle Image und die Laufzeiteinstellungen, lies anschließend den Update-Pfad und ersetze erst danach das Image. Teste danach dieselben Bibliotheken, Benutzer, Wiedergabemodi, geplanten Aufgaben und das Neustartverhalten, bevor du die Rollback-Kopie löschst.

Zuletzt funktionierendes Image und Container-Definition dokumentieren

Notiere den aktuellen Jellyfin-Image-Tag und, wenn möglich, auch dessen Digest. Exportiere oder kopiere die Compose-Datei oder App-Definition mit Ports, Netzwerken, Mounts, Umgebungsvariablen, Neustart-Richtlinie, Benutzerzuordnung, zusätzlichen Gruppen, GPU-Geräten und etwaigen Reverse-Proxy-Beziehungen.

Die offizielle Dokumentation zu Jellyfin-Containern unterscheidet zwischen veränderlichen Tags wie latest und expliziten Major-, Minor- und Patch-Tags. Verhalten der Jellyfin-Image-Tags Ein Rollback ist einfacher, wenn du die genaue funktionierende Version kennst, statt dich nur daran zu erinnern, dass „latest gestern noch funktioniert hat“.

Entferne das alte Image nicht und lösche die gespeicherte Definition erst, wenn die neue Version den vollständigen Validierungszeitraum bestanden hat. Falls das Upgrade fehlschlägt, bevor persistente Daten verändert wurden, bieten das aufbewahrte Image und die Definition den Wiederherstellungspfad mit den geringsten Eingriffen.

Wiederherstellbares Backup des Jellyfin-Zustands erstellen

Sichere die Jellyfin-Daten- und Konfigurationsverzeichnisse, bevor du das Image änderst. Das Backup muss außerhalb des aktiven Anwendungspfads liegen und unabhängig davon lesbar sein. Eine zweite Kopie oder ein Snapshot auf demselben Datensatz ist nur dann nützlich, wenn du weißt, gegen welchen Ausfall er schützt.

Jellyfins Backup-Dokumentation warnt, dass bei Upgrades eine Wiederherstellung der Daten erforderlich sein kann, da es nach durchgeführten Migrationen keine allgemeine Möglichkeit gibt, ein Downgrade vorzunehmen. Sie dokumentiert außerdem integrierte Backups und die erforderliche saubere Beendigung für manuelle Dateikopien. Anleitung zum Sichern und Wiederherstellen von Jellyfin

Für Container-Workflows wird dasselbe Prinzip durch den Rollback-Punkt-Workflow vor dem Update von ZimaSpace abgedeckt. Halte hier an, wenn du die persistenten Pfade nicht identifizieren oder den Inhalt des Backups nicht überprüfen kannst.

Mounts, UID/GID und Hardwareabhängigkeiten erfassen

Liste alle Bind-Mounts und benannten Volumes auf und notiere, ob sie schreibgeschützt oder beschreibbar sind. Halte die Laufzeit-UID/GID, Gruppenmitgliedschaften und Eigentumsverhältnisse der Jellyfin-Datenverzeichnisse fest. Erfasse auch GPU- oder Rendergeräte-Zuordnungen, falls Hardwarebeschleunigung aktiviert ist.

Jellyfins Container-Anleitung zeigt, dass Medien, Konfiguration und Cache separat eingebunden werden und der Container mit 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 und dabei trotzdem ein leeres Konfigurationsverzeichnis vorfinden oder den Zugriff auf ein Gerät verlieren.

Vergleiche die gespeicherte Definition mit dem tatsächlich laufenden Container und nicht nur mit einer Vorlage, von der du annimmst, dass sie aktuell ist. Wenn manuelle Änderungen an der Laufzeitumgebung in Compose oder der NAS-App-Definition fehlen, behebe diese Abweichungen vor dem Upgrade, damit sich die vorherige Bereitstellung reproduzieren lässt.

Featured

ZimaCube 2 persönliche Cloud-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prüfe den unterstützten Upgrade-Pfad und die Plugin-Risiken

Lies die Versionshinweise zu allen Hauptversionsgrenzen zwischen der aktuellen und der Zielversion. Achte auf erforderliche Zwischenversionen, Datenbankmigrationen, geänderte Konfigurationen, Plugin-Kompatibilität, FFmpeg-Anforderungen oder langwierige Startvorgänge.

Jellyfins Upgrade-Dokumentation betont immer wieder, wie wichtig Backups sind, und erklärt, warum Änderungen am Schema ein einfaches Downgrade unmöglich machen können. Upgrade- und Downgrade-Grenzen In den Versionshinweisen zu Hauptversionen können versionsspezifische Voraussetzungen stehen. Gehe daher nicht davon aus, dass ein Versionssprung sicher ist, nur weil es ein Container-Image gibt.

Ist ein Plugin unverzichtbar, prüfen Sie vor dem Server-Upgrade, ob eine kompatible Version verfügbar ist. Ist ein Plugin optional und hat es den Start in der Vergangenheit verhindert, notieren Sie die aktuelle Version und stellen Sie sich darauf ein, nur dieses Plugin zu deaktivieren, falls die Protokolle des neuen Servers es als Fehlerursache ausweisen.

Führen Sie das Upgrade durch, ohne die Grenze des Datenbestands zu verändern

Beenden Sie Jellyfin ordnungsgemäß, laden Sie das vorgesehene Image herunter und erstellen Sie nur den Jellyfin-Dienst mit denselben überprüften persistenten Pfaden und Laufzeitabhängigkeiten neu. Kombinieren Sie das Upgrade nicht mit einer Speichermigration, einer Neugestaltung von UID/GID, einer Änderung der Reverse-Proxy-Konfiguration und einer GPU-Neukonfiguration, es sei denn, genau diese Änderungen sind der Zweck der Wartungsarbeiten.

Beobachten Sie das Protokoll beim ersten Start. Bei einer großen Bibliothek kann eine Migration durchaus einige Zeit dauern. Meldungen wie „permission denied“, eine leere Datenbank, ein fehlender Pfad oder ein inkompatibles Schema unmittelbar nach dem Start weisen dagegen auf eine andere Ursache hin. Starten Sie eine Migration nicht wiederholt neu, nur weil die Benutzeroberfläche nicht sofort verfügbar ist.

Wird der Container wie ein neuer Server gestartet, stoppen Sie ihn, bevor Sie irgendetwas konfigurieren. Dieses Symptom bedeutet meist, dass der neue Dienst auf den falschen persistenten Datenbestand verweist. Korrigieren Sie zuerst die Einbindung. Das Konfigurieren einer neuen, leeren Instanz kann neue Dateien erzeugen, die den Wiederherstellungsweg verschleiern.

Validieren Sie die neue Version, bevor Sie Rollback-Dateien entfernen

Überprüfen Sie die ursprüngliche Serveridentität, Benutzer, Bibliotheken, Metadaten und wichtigen Einstellungen. Spielen Sie ein Element mit Direct Play und eine repräsentative Transkodierung ab. 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 Fehler bei Migrationen, Datenbanken, Berechtigungen und FFmpeg.

Starten Sie den Container nach der ersten erfolgreichen Sitzung einmal neu. Die neue Version ist erst vollständig validiert, wenn sie nach einer sauberen Neuerstellung oder einem Neustart auf dieselben Daten und Geräte zugreifen kann. So erkennen Sie, ob versehentlich eine temporäre Einbindung oder ein flüchtiger Laufzeitzustand vorausgesetzt wird.

Bewahren Sie das Backup vor dem Upgrade, den Verweis auf das vorherige Image und die gespeicherte Definition auf, bis der Server sein übliches Auslastungsfenster ohne Probleme durchlaufen hat. Ist nach einer Datenbankmigration ein Rollback erforderlich, befolgen Sie die dokumentierten Wiederherstellungsgrenzen von Jellyfin, statt ein älteres Image auf einen bereits migrierten Datenbestand anzusetzen.