So trennst du Jellyfin-App-Daten, Cache und Backups

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Separate Jellyfin App Data, Cache, and Backups - Zima Store Online

Trennen Sie Jellyfin-App-Daten, Cache und Backups, indem Sie klären, was einen Neuaufbau überstehen muss, was neu erzeugt werden kann und was nach dem Ausfall des Geräts mit dem aktiven Zustand weiterhin verfügbar sein muss. Diese drei Rollen können sich in einem kleinen Server eine physische SSD teilen, sollten aber nicht denselben Lebenszyklus oder dieselbe Wiederherstellungsrichtlinie haben.

Zum dauerhaften Anwendungszustand gehören die Datenbank, die Konfiguration, Benutzer- und Wiedergabestatus sowie weitere Dateien, die erforderlich sind, um denselben Server wiederherzustellen. Cache- und Transcodierungsdaten sind entbehrlich, sobald keine aktive Aufgabe sie mehr benötigt. Backups sind Wiederherstellungskopien und sollten nicht von derselben Speichergrenze abhängen, die sie wiederherstellen sollen.

Machen Sie dauerhafte App-Daten zur maßgeblichen Zustandsrolle

Ermitteln Sie zunächst den Host-Pfad oder das Volume, in dem der dauerhafte Zustand von Jellyfin gespeichert ist. Bei einer Container-Bereitstellung kann das Image ersetzt werden; der eingebundene Zustand muss nach der Neuerstellung des Containers wieder verbunden werden. Dokumentieren Sie Host-Pfad, Container-Pfad, Besitzer, Dateisystem, Mindestreserve an freiem Speicher und Sicherungsmethode.

Ein aktuelles Jellyfin-Docker-Compose-Layout trennt persistente Konfigurations- und Cache-Verzeichnisse, bevor Medien eingebunden werden. Diese Pfadtrennung ist auch dann betrieblich sinnvoll, wenn beide Verzeichnisse zunächst auf derselben SSD liegen.

Legen Sie die maßgebliche Datenbank nicht an einem Ort ab, den Sie bei der Fehlersuche bedenkenlos leeren würden. Eine erfolgreiche Cache-Bereinigung darf niemals Benutzer, Bibliotheken, Wiedergabestatus oder die Serveridentität zurücksetzen können.

Behandeln Sie Cache- und Transcodierungsbereich als wiederherstellbare Arbeitsdaten

Cache dient dazu, wiederholte Arbeit zu reduzieren oder temporäre Verarbeitungsergebnisse aufzunehmen. Sein Wert liegt in Leistung und Komfort, nicht in der Identität. Stellen Sie ausreichend Kapazität für die größten normalen Spitzen bei Hintergrundaufgaben und Transcodierung bereit, ermöglichen Sie aber eine Neuerstellung, ohne den gesamten Server wiederherstellen zu müssen.

Verhindern Sie, dass stark veränderliche Cache- oder Transcodierungsaktivitäten die Backup-Richtlinie für die Datenbank bestimmen. Wenn dasselbe schnelle Gerät beide Rollen übernimmt, verwenden Sie getrennte Verzeichnisse oder Datasets mit eigenen Kontingenten und Überwachungsregeln. So kann eine vorübergehende Spitze nicht den freien Speicher verbrauchen, der für Datenbankschreibvorgänge oder eine künftige Wiederherstellung benötigt wird.

Wenn das Durchsuchen sowie Metadaten- und Zustandsvorgänge langsam wirken, während sequenzielle Medienlesevorgänge weiterhin problemlos funktionieren, bietet die ZimaSpace-Analyse zum Speichern interaktiver Medienserverdaten auf einer SSD einen sinnvollen nächsten Test, ohne die umfangreiche Medienbibliothek als dieselbe Speicherarbeitslast zu behandeln.

Der Container ist entbehrlich; Zustand und Wiederaufbauanleitung sind es nicht

Ein Container kann erneut abgerufen werden; es kann jedoch nicht vorausgesetzt werden, dass seine Bereitstellungsdefinition und persistenten Daten wieder auftauchen. Speichern Sie die Compose- oder Dienstdefinition, die Image-Version oder Tag-Strategie, die Zuordnung der Einbindungen, die Dienstidentität, Verweise auf erforderliche Geheimnisse sowie den persistenten Jellyfin-Zustand.

Die praktische Regel in diesem Backup-Workflow für Docker-Volumes lautet, dass für die Wiederherstellung relevante Daten in Volumes, Bind-Mounts, App-Daten und Dienstdefinitionen liegen – nicht im entbehrlichen Container selbst.

Bei aktiven Datenbanken ist die Konsistenz wichtiger, als jedes Byte zu kopieren, während der Dienst ausgelastet ist. Verwenden Sie den unterstützten Sicherungsweg der Anwendung oder eine kontrollierte Stopp-/Snapshot-Methode, die zur Bereitstellung passt, anstatt eine beliebige Kopie laufender Dateien als nachweislich geeigneten Wiederherstellungspunkt zu betrachten.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Ein Backup neben dem aktiven Zustand schützt nicht vor einem Host-Ausfall

Ein Backup neben der aktiven Datenbank kann vor versehentlichen Änderungen schützen, übersteht jedoch nicht jeden Pool-, Host-, Ransomware-, Diebstahl- oder Stromausfall, durch den die Produktionsdaten entfernt werden können. Bewahren Sie eine Wiederherstellungskopie auf einem anderen Gerät oder innerhalb einer anderen administrativen Grenze auf und schützen Sie alle Schlüssel oder Zugangsdaten, die zum Lesen dieser Kopie erforderlich sind.

Ein Backup-Plan für Self-Hosting sollte Zustand, Geheimnisse, Wiederherstellungskopien und Wiederherstellungsanweisungen gemeinsam abbilden. Dieses Wiederherstellungs-Audit für Self-Hosting legt den Schwerpunkt auf Kopien außerhalb des offensichtlichen Schadensbereichs und dokumentierte Wiederaufbauvoraussetzungen, statt Snapshots als vollständigen Plan zu zählen.

Verhindern Sie, dass das Backup-Ziel durch dieselbe Cache-Aufbewahrungsregel oder denselben Bereinigungsbefehl wie der aktive App-Pool geleert wird. Das Backup ist eine separate Rolle, selbst wenn es vorübergehend auf demselben Gehäuse gespeichert wird.

Ordnen Sie die Speicherrollen zu, bevor Sie Laufwerke kaufen oder verschieben

Rolle	Beispiele	Kann sie neu erstellt werden?	Primäre Richtlinie
Dauerhafter App-Zustand	Datenbank, Konfiguration, Benutzer, Wiedergabestatus, Plugins/Einstellungen	Nicht kostengünstig	Geringe Latenz, freier Speicher, konsistentes Backup
Cache / temporär	Cache, Transcodierungs-Arbeitsbereich, entbehrliche Zwischendateien	Ja	Kapazität, Leistung, begrenzte Bereinigung
Backup	Versionierte Zustandskopie, Bereitstellungsdefinition, Wiederherstellungsmetadaten	Nein; es ist die Wiederherstellungsquelle	Unabhängige Fehlerdomäne, Aufbewahrung, Wiederherstellungstest
Medien	Filme, Serien, Familienvideos	Hängt von der Quelle ab	Kapazität und separate Schutzrichtlinie

Diese Zuordnung verhindert einen häufigen Fehler bei der Neugestaltung: alles auf das schnellste Laufwerk zu verschieben, obwohl nur die Latenz des App-Zustands problematisch war, oder jede temporäre Datei zu sichern, während die für den Wiederaufbau des Containers erforderliche Dienstdefinition fehlt.

Beweisen Sie die Trennung mit einer Testwiederherstellung

Stellen Sie den Jellyfin-Zustand in einem neuen Pfad oder auf einem isolierten Host wieder her, verweisen Sie mit einer kopierten Bereitstellungsdefinition auf diesen Speicherort, gewähren Sie nicht destruktiven Zugriff auf repräsentative Medien und starten Sie den Dienst ohne den ursprünglichen Cache. Der Server sollte mit der erwarteten Identität, den Bibliotheken, Benutzern und Einstellungen zurückkehren, auch wenn der Cache zunächst leer ist.

Die Unterscheidung wird erst messbar, wenn ein Backup in einem isolierten Ziel wiederhergestellt und überprüft wird, ohne den Produktionszustand zu verwenden. Die Testinstanz von Jellyfin sollte aus der Wiederherstellungskopie starten, die erforderlichen Pfade erneut verbinden und nachweisen, dass das aktive Volume die Wiederherstellung nicht heimlich vervollständigt.

Das Layout ist erfolgreich, wenn der Cache gelöscht werden kann, ohne die Identität zu verlieren, die Laufzeitumgebung neu erstellt werden kann, ohne die Bibliothek aus dem Gedächtnis rekonstruieren zu müssen, und mindestens ein Backup den Dienst wiederherstellen kann, nachdem das Gerät mit den aktiven App-Daten als nicht verfügbar angenommen wurde.