Jellyfin-Datenpfade erklärt: Was dauerhaft gespeichert werden muss und was neu erstellt werden kann

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.

Jellyfin Data Paths Explained: What Must Persist and What Can Be Rebuilt

Jellyfin lässt sich sicherer betreiben, wenn Datenbankstatus, Konfiguration, Metadaten, Cache, temporäre Transkodierungen und Medien als unterschiedliche Datenrollen behandelt werden.

Nicht jedes Verzeichnis benötigt dieselbe Speicherklasse oder Sicherungsrichtlinie: Benutzerkonten und Wiedergabestatus müssen einen Laufzeitaustausch überstehen, während Cache und Transkodierungs-Arbeitsdaten in der Regel neu erstellt werden können und die Medien an anderer Stelle maßgeblich bleiben. Durch die Zuordnung dieser Rollen wird verhindert, dass ein Container-Update oder eine Datenträgerbereinigung versehentlich den Server zurücksetzt. Definieren Sie die Persistenz danach, ob die Daten eine saubere Neuerstellung der Laufzeitumgebung überstehen müssen.

Datenbank und Konfiguration definieren den Serverstatus

Datenbank und Konfiguration enthalten Benutzer, Bibliotheksdefinitionen, Einstellungen, Wiedergabestatus und weitere identitätsbezogene Daten. Ihr Verlust kann dazu führen, dass die Mediendateien zwar intakt bleiben, der Server selbst jedoch praktisch von vorn beginnt.

Der Konfigurationsstatus von Jellyfin umfasst Benutzerkonten, Bibliothekseinstellungen, Wiedergabeverlauf und Metadaten, die getrennt von den umfangreichen Mediendateien geschützt werden sollten.

Bewahren Sie diesen Status auf einem persistenten Pfad außerhalb des ersetzbaren Images oder Pakets auf. Eine persistente App-Datenstruktur bietet der Laufzeitumgebung einen stabilen Ort, an dem sie sich nach einer Neuerstellung wieder verbinden kann.

Metadaten sind wertvoll, aber nicht mit der Datenbank identisch

Grafiken und generierte Metadaten können bei großen Bibliotheken aufwendig neu erstellt werden, selbst wenn einige Quelldaten wiederherstellbar sind. Ihre Wiederherstellungspriorität hängt davon ab, wie viel manuelle Pflege und Verarbeitung darin steckt.

Wenn sich Containerdaten auf einer SSD befinden, während umfangreiche Mediendaten auf einer HDD verbleiben, entsteht eine klare Trennung von SSD-App-Daten und HDD-Medien. Dadurch werden die Latenz beim Durchsuchen und die Speicherung großer Medienbestände voneinander getrennt.

Messen Sie die Größe der Metadaten und den Aufwand für ihre Neuerstellung, bevor Sie entscheiden, ob sie in jede Sicherungsebene aufgenommen werden. Behandeln Sie manuell bearbeitete oder nur schwer neu generierbare Inhalte anders als entbehrlichen Cache.

Cache und Transkodierungs-Arbeitsdaten benötigen ein Ablaufmodell

Cache und aktive Transkodierungsausgaben dienen dazu, aktuelle Vorgänge zu beschleunigen oder zu unterstützen, und definieren nicht die langfristige Identität des Servers. Eine unkritische Sicherung dieser Daten vergrößert die Backups und kann veraltete temporäre Zustände wiederherstellen.

Ein Speicherkonzept für Medienserver trennt den lokalen Cache von dauerhaften Mediendaten, da temporäre Daten mit hoher Änderungsrate andere Anforderungen an Latenz und Haltbarkeit stellen.

Platzieren Sie die Arbeitsdaten auf einem schnellen Pfad und überwachen Sie den freien Speicherplatz ausdrücklich. Stellen Sie sicher, dass der Dienst sie nach dem Löschen neu erstellen kann, bevor Sie sie von der Sicherung ausschließen.

-15% OFF

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

Single board computer zimaboard2

Medien sollten eine separate maßgebliche Speicherebene bleiben

Die Bibliotheksdateien können auf lokalen Datenträgern oder einem NAS liegen und den Umfang der Anwendungsdaten um ein Vielfaches übersteigen. Sie benötigen eine eigene Entscheidung zu Redundanz und Sicherung, statt automatisch die Richtlinie der Datenbank zu übernehmen.

Kapazität und Änderungsrate von Sicherungen variieren je nach Datensatz. Daher passt ein einziges Aufbewahrungsmodell nur selten sowohl zu Anwendungsstatus als auch zu umfangreichen Mediendaten.

Dokumentieren Sie, welcher Pfad für jede Rolle maßgeblich ist, und testen Sie eine Wiederherstellung, bei der der Jellyfin-Status erneut mit einer unveränderten Medienbibliothek verbunden wird. Eine klare Rollenzuordnung macht künftige Speichermigrationen deutlich weniger unübersichtlich.