So migrieren Sie Jellyfin von einem Container zu einem ausfallsicheren Service-Stack

Migriere Jellyfin, indem du zuerst das aktuelle Verhalten dokumentierst, dann den persistenten Status schützt und anschließend Dienste in reversiblen, getesteten Schritten hinzufügst.

Dieses Verfahren ist für einen funktionierenden Docker-Container gedacht, dessen undokumentierter Startbefehl oder All-in-one-Aufbau an Grenzen stößt. Ziel ist nicht die größtmögliche Anzahl an Containern, sondern ein reproduzierbarer Jellyfin-Dienst mit klar definierten Mounts, Netzwerken, Geräten, Zustandsanzeigen, Sicherungsumfang und Rollback. Halte den Medienspeicher unabhängig vom Anwendungsstatus, behalte die alte Instanz bei, bis die Abnahmetests bestanden sind, und füge nur Abhängigkeiten hinzu, die der Haushalt betreiben kann.

Festlegen, welche Ausfälle abgefangen werden müssen

Lege fest, welche Ausfälle der neue Stack bewältigen soll: einen Absturz des Jellyfin-Prozesses, ein fehlerhaftes Image-Update, verlorenen Konfigurationsspeicher, einen nicht verfügbaren Proxy, einen Neustart des Hosts oder den vollständigen Verlust des Hosts. Für jedes Szenario ist eine andere Maßnahme erforderlich. Eine Neustartrichtlinie hilft nach einem Prozessabbruch; sie stellt weder ein gelöschtes Volume wieder her noch repariert sie einen nicht erreichbaren Medien-Mount.

Lege messbare Wiederherstellungsziele für Konfiguration, Wiedergabestatus und Dienstverfügbarkeit fest. Entscheide, wie viel Ausfallzeit und Datenverlust akzeptabel sind, wer eine Warnung erhält und welche Komponenten sich neu erstellen lassen. Dieser Rahmen verhindert, dass eine kleine Migration zu Hause Datenbanken, Proxys, Dashboards und Automatisierung anhäuft, die kein konkretes Risiko mindern.

Den laufenden Container erfassen

Dokumentiere die genaue Image-Referenz, den Befehl, die Umgebungsvariablen, veröffentlichte Ports, Netzwerke, Neustartrichtlinie, Benutzer- und Gruppen-IDs, Gerätezuordnungen, DNS-Einstellungen, Labels, Konfigurations-Mount, Cache-Mount, Medien-Mounts und Secrets. Erfasse außerdem Eigentümer und Berechtigungen aller Host-Pfade. Ein Screenshot der Container-Oberfläche ist keine vollständige Bereitstellungsdokumentation.

Übertrage diese Bestandsaufnahme in eine Compose-Definition, ohne das Verhalten zu ändern. Die schrittweise Anleitung zur Übertragung jeder einzelnen Option in diesem Leitfaden zur Migration von Docker run zu Compose ist wertvoll, weil sie Reproduzierbarkeit als ersten Meilenstein setzt, nicht die Erweiterung des Funktionsumfangs. Fixiere für die erste Umstellung den derzeit laufenden Image-Digest oder die Version.

Persistenten Status, Cache und Medien trennen

Ordne die Jellyfin-Konfiguration und den Datenbankstatus einem eindeutig benannten persistenten Pfad zu. Lege flüchtige Cache- und Transcode-Daten in einem separaten Pfad ab, damit sie nicht mit kritischen Sicherungsdaten verwechselt werden. Binde eigene Medien unabhängig und, sofern der Arbeitsablauf es zulässt, schreibgeschützt ein; eine ausfallsichere Anwendungsschicht sollte die Schutzgrenze einer großen Mediathek nicht verwischen.

Stoppe Jellyfin oder versetze es in einen ruhenden Zustand, bevor du die erste Sicherung des konsistenten Zustands erstellst, es sei denn, die Backup-Methode garantiert Anwendungskonsistenz. Halte Berechtigungen, Prüfsummen oder Dateianzahlen, den Zeitpunkt des Backups und den Speicherort der Wiederherstellung fest. Gehe nie davon aus, dass das Container-Image Nutzerdaten enthält: Die Bereitstellungsdefinition, Geheimnisse, der persistente Zustand und die Medienverweise sind getrennte Bestandteile der Wiederherstellung.

Featured

ZimaCube 2 persönliche Cloud-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Wiederherstellung testen, bevor du das Netzwerk änderst

Erstelle ein temporäres Wiederherstellungsziel, kopiere den geschützten Anwendungszustand dorthin und starte den Jellyfin-Dienst mit festem Image-Tag an einem alternativen Port, wobei die Medien schreibgeschützt eingebunden sind. Überprüfe Benutzer, Bibliotheken, Wiedergabeverlauf, Metadaten, Plugins und repräsentative Wiedergabevorgänge. Lösche die temporäre Instanz und wiederhole den Vorgang anhand der schriftlichen Anleitung, falls ein Schritt vom Gedächtnis abhing.

Ein praktisches Compose-Backup muss die Bereitstellungsdatei, Umgebungsvariablen und -dateien, Volumes sowie einen anwendungskonsistenten Datenbankexport enthalten. In dieser Anleitung zu Compose-Backups und -Upgrades wird erklärt, warum das Kopieren eines Images oder laufender Datenbankdateien allein keinen vollständigen Wiederherstellungsweg bietet.

Auf den deklarativen Jellyfin-Dienst umstellen

Wähle ein Wartungsfenster, stoppe den alten Container, erstelle ein abschließendes Backup des konsistenten Zustands und verhindere, dass die alte Instanz automatisch neu startet. Starte den entsprechenden Compose-Dienst mit denselben persistenten Pfaden und demselben Gerätezugriff. Behalte die öffentliche Route erst dann unverändert bei, wenn die lokalen Zustands- und Wiedergabeprüfungen erfolgreich sind.

Überprüfe den Zustand der Container, Protokolle, die Sichtbarkeit der Bibliotheken, den Zugriff auf Hardwaregeräte, Direct Play, eine repräsentative Transkodierung, die Untertitelverarbeitung und einen Neustart. Kann der Dienst ein Gerät oder einen Mount nicht sehen, halte an und stelle den alten Container wieder her, anstatt unter Zeitdruck mehrere Ebenen zu bearbeiten. Für das Rollback benötigst du das vorherige Image mit festem Tag sowie den Zustand vor der Umstellung und die ursprünglichen Startparameter.

Angrenzende Dienste schrittweise hinzufügen

Führe einen Reverse-Proxy nur dann ein, wenn der externe Zugriff eine separat verwaltete Route erfordert. Ergänze Monitoring, wenn es ein definiertes Gesundheitssignal gibt und jemand darauf reagiert. Füge einen Benachrichtigungskanal hinzu, wenn Neustartschleifen, Speicherverluste oder fehlgeschlagene Backups bemerkt werden müssen. Für jeden Dienst müssen eine verantwortliche Person, eine Entscheidung zum persistenten Zustand, der Netzwerkbereich, die Aktualisierungsmethode und die Auswirkungen eines Ausfalls festgelegt sein.

Der architektonische Grund für diese Grenzen wird separat in ZimaSpaces Erklärung zu den Gründen für Service-Stacks bei Jellyfin-Bereitstellungen behandelt. Wende dieses Modell während der Migration vorsichtig an: Gruppiere Komponenten, die gemeinsam wiederhergestellt werden müssen, und vermeide es, die Wiedergabe von optionalen Dashboards oder Automatisierungen abhängig zu machen.

Machen Sie Zustandsprüfungen, Updates und Sicherungen nachvollziehbar

Definieren Sie den Zustand anhand des Benutzerpfads und nicht nur anhand eines laufenden Prozesses. Prüfen Sie, ob Jellyfin lokal antwortet, der Medien-Mount verfügbar ist, die öffentliche Route bei Aktivierung zum vorgesehenen Dienst führt und eine bekannte Datei gelesen werden kann. Leiten Sie fehlgeschlagene Prüfungen an einen Benachrichtigungskanal weiter, den der Betreiber bereits nutzt, und liefern Sie genügend Kontext, um zwischen einem Anwendungsfehler und einem Speicher- oder Netzwerkausfall unterscheiden zu können.

Verwalten Sie die Compose-Definition per Versionskontrolle, halten Sie Secrets aus dem Repository heraus und prüfen Sie Image-Änderungen vor der Bereitstellung. Automatisieren Sie Sicherungen erst, wenn eine manuelle Wiederherstellung funktioniert. Der Ablauf in diesem Leitfaden zu Jellyfin-Zustandsprüfungen und Monitoring veranschaulicht das Zusammenspiel von Definitionen, Prüfungen, Warnmeldungen und Sicherungen; behalten Sie für Updates, die gespeicherte Daten verändern können, einen Freigabe- und Rollback-Punkt bei.

Führen Sie Ausfalltests durch, bevor Sie den alten Pfad außer Betrieb nehmen

Starten Sie den Host neu, stoppen Sie Jellyfin unerwartet, machen Sie den Proxy nicht verfügbar, trennen Sie einen Medienpfad zum Testen und stellen Sie den Anwendungszustand an einem sauberen temporären Speicherort wieder her. Bestätigen Sie bei jeder Übung den erwarteten Alarm, die Wiederherstellungsreihenfolge und das für Benutzer sichtbare Verhalten. Simulieren Sie keinen zerstörerischen Speicherausfall, wenn es nur eine einzige Medienkopie gibt.

Halten Sie die Wiederherstellungszeit und alle manuellen Befehle fest. Ein Container, der schnell neu startet, aber mit einer leeren Bibliothek zurückkehrt, hat den Diensttest nicht bestanden. Eine Sicherung, die zwar vorhanden ist, sich aber nicht innerhalb des vorgesehenen Zeitfensters wiederherstellen lässt, hat den Wiederherstellungstest nicht bestanden. Beheben Sie diese Schwachstellen, bevor Sie weitere Dienste hinzufügen.

Schließen Sie die Migration mit einer stabilen Betriebsvereinbarung ab

Nehmen Sie den ursprünglichen Container erst außer Betrieb, wenn der neue Jellyfin-Dienst den normalen Gebrauch im Haushalt, ein geplantes Update, einen Neustart des Hosts und eine vollständige Wiederherstellungsprobe erfolgreich überstanden hat. Archivieren Sie gemäß der gewählten Aufbewahrungsrichtlinie die alten Parameter, die letzte Sicherung vor der Umstellung, die aktuelle Compose-Definition, die Methode zur Wiederherstellung der Secrets, die Mount-Übersicht und die Schritte für ein Rollback.

Erweitern Sie den Stack nicht weiter, sobald er reproduzierbar, überwacht, wiederherstellbar und für den Betreiber verständlich ist. Fügen Sie nur dann einen weiteren Knoten oder eine weitere Abhängigkeit hinzu, wenn eine gemessene Kapazitäts-, Vertrauens- oder Fehlerdomänenanforderung dies erfordert. Resilienz entsteht durch einen bekannten Zustand und eingeübte Wiederherstellung, nicht durch die Anzahl der Container im Diagramm.