Ein Jellyfin-Setup mit zwei Speichern: SSD für Metadaten und HDD für Daten

Eva Wong ist die technische Redakteurin und begeisterte Tüftlerin bei ZimaSpace. Als lebenslanger Geek mit einer Leidenschaft für Homelabs und Open-Source-Softwarehat sie sich darauf spezialisiert, komplexe technische Konzepte in verständliche, praxisnahe Anleitungenzu übersetzen. Eva ist überzeugt, dass Self-Hosting Spaß machen sollte und nicht einschüchternd sein darf. Mit ihren Tutorials hilft sie der Community dabei, Hardware-Setups zu durchschauen, vom Bau des ersten NAS bis zum sicheren Umgang mit Docker-Containern.

Bei einer leistungsstarken Jellyfin-Konfiguration mit zwei Speichermedien liegen der latenzempfindliche Anwendungszustand und aktive Metadaten auf einer SSD, während große Mediendateien platzsparend auf HDDs gespeichert werden.

Nicht jede Jellyfin-Datei benötigt das schnellste Laufwerk. Datenbanken, Grafikindizes, Vorschaubilder und Caches führen zu vielen kleinen Suchvorgängen; Filme und Musik werden hauptsächlich in großen sequenziellen Zugriffen gelesen; temporärer Transcode-Speicher ist nur vorübergehend im Einsatz und kann viele Schreibvorgänge verursachen. Weisen Sie jeder Aufgabe eine Speicherebene zu, deren Latenz, Kapazität, Lebensdauer, Sicherungs- und Wiederherstellungsverhalten zum jeweiligen Arbeitsablauf passen. Testen Sie anschließend die Gesamtkonfiguration während Bibliotheksscans und der Wiedergabe.

SSD und HDD unterschiedliche Aufgaben zuweisen

Verwenden Sie die SSD für das Betriebssystem oder die App-Daten der Container, die Jellyfin-Datenbank, Konfiguration, aktive Metadaten, Indizes und den Cache. Speichern Sie umfangreiche Film-, Serien-, Musik- und Heimvideodateien auf dem HDD-Pool. Behandeln Sie den Transcode-Speicher als separate Entscheidung: Er kann auf einer SSD liegen, wenn Speicherplatz und Lebensdauer ausreichen, oder auf einem anderen schnellen temporären Speicherpfad, wenn gleichzeitige Transcodierungen viele Schreibvorgänge verursachen.

Ein praktischer Leitfaden zu SSD-Arbeitslasten im Homelab unterscheidet ebenfalls nach Aufgabenbereichen: Datenbanken und aktive Anwendungen profitieren von Flash-Speicher mit niedriger Latenz, während Speicherebenen mit hoher Kapazität nicht allein deshalb NVMe-Leistung benötigen, weil schnellere Speicher verfügbar sind.

Teilen Sie die Daten nicht allein nach Ordnernamen auf. Manche „Metadaten“ sind maßgeblich oder manuell gepflegt und sollten gesichert werden, während sich ein Bild-Cache neu erstellen lässt. Die Einrichtung ist im Fehlerfall wiederherstellbar, wenn Sie wissen, welche Inhalte der SSD wiederhergestellt werden müssen und welche sich aus den Medien neu erstellen lassen.

Zufällige Zugriffe auf den App-Zustand auf einer SSD speichern

Das Durchsuchen von Jellyfin, Suchvorgänge, Aktualisierungen des Benutzerstatus, das Abrufen von Grafiken, Datenbanktransaktionen und viele Bibliotheksvorgänge reagieren empfindlich auf Latenzen, anders als das sequenzielle Lesen eines Films. Wenn Sie diese App-Daten von einer HDD auf eine SSD verschieben, entfällt die mechanische Suchzeit, und die vielen kleinen Metadatenzugriffe stören die großen Medienzugriffe weniger.

Ein aktueller Jellyfin-Leistungsleitfaden nennt langsamen Metadatenspeicher als direkte Ursache für das träge Durchsuchen der Bibliothek, da die App-Daten viele kleine Lesezugriffe verursachen. ZimaSpaces Jellyfin-Analyse zu SSDs im Vergleich zu HDDs kommt zur gleichen Aufgabenverteilung: Die Latenz des App-Zustands profitiert von einer SSD, während umfangreiche Mediendateien auf einer HDD bleiben können.

Bemessen Sie die SSD anhand des tatsächlichen Wachstums der Anwendungsdaten plus Reserve und nicht anhand der Medienkapazität. Lassen Sie freien Speicherplatz für das Datenbankwachstum, Metadaten, Trickplay oder Coverbilder, sofern aktiviert, lokal erstellte Backups vor dem Export sowie die größte temporäre Arbeitslast, die Sie bewusst dort unterbringen. Eine kleine, volle SSD ist schlechter als eine größere, nur mäßig gefüllte SSD mit stabiler Speicherplatzreserve.

Lassen Sie große Medienbestände auf HDD, sofern keine andere Anforderung die Entscheidung ändert

HDDs bleiben als Speicherebene für Medien sinnvoll, da ein Filmstream in der Regel ein anhaltender sequenzieller Lesevorgang ist, dessen Bitrate weit unter dem Durchsatz einer intakten modernen Festplatte liegt. Kapazität pro Euro, Laufwerksschächte, Redundanz und Backups geben meist lange den Ausschlag, bevor die SSD-Schnittstellengeschwindigkeit für die Mediendatei selbst relevant wird.

Ein Jellyfin-NAS-Betreiber beschreibt ein Layout mit Containern auf SSD und Medien auf HDD, bei dem das Durchsuchen dank der SSD schnell geht, die Wiedergabe aber 15–20 Sekunden wartet, wenn schlafende Festplatten erst aufwachen müssen. Das veranschaulicht den tatsächlichen Zielkonflikt: Es geht nicht um anhaltende Bandbreite, sondern um die Latenz beim ersten Lesezugriff und das Verhalten der Energieverwaltung.

Wenn ein sofortiger Start wichtiger ist als die Energieeinsparung durch heruntergefahrene Laufwerke, lassen Sie die Mediendatenträger während der üblichen Wiedergabezeiten eingeschaltet oder passen Sie deren Energieverwaltung an. Wenn Ihnen ein leiser, stromsparender Betrieb wichtiger ist, nehmen Sie die Verzögerung beim Aufwachen vor der ersten Wiedergabe in Kauf. Alle Medien nur deshalb auf SSDs zu verschieben, um eine kurze Anlaufpause zu vermeiden, ist in der Regel eine Entscheidung über Kapazitätskosten und keine Anforderung von Jellyfin.

Schützen Sie die SSD als kleine, aber kritische Wiederherstellungseinheit

Die SSD enthält möglicherweise deutlich weniger Daten als der HDD-Pool, aber darauf liegt der Zustand, durch den sich der Server wie dieselbe Jellyfin-Instanz anfühlt. Ein Ausfall der SSD mit den Anwendungsdaten kann Benutzer, Wiedergabeverlauf, Konfiguration, Playlists und kuratierte Metadaten löschen, obwohl alle Filme intakt bleiben. Sichern Sie diese kleine Wiederherstellungseinheit regelmäßig und außerhalb der Fehlerdomäne der SSD.

Ein Dual-Tier-Layout funktioniert am besten, wenn der auf der SSD gespeicherte Anwendungsstatus über einen eigenen, getesteten Wiederherstellungsweg verfügt. Ein Workflow zum Testen der Wiederherstellung legt den Schwerpunkt darauf, die Anwendung auf einem isolierten Ziel zu überprüfen, statt kopierte Dateien als Beweis zu betrachten. Sichern Sie serverspezifische Zustände in versionierten SSD-Backups und bewahren Sie ausgewählte Medien-Begleitdateien nur dann auf, wenn sie die Migration oder den Wiederaufbau erleichtern.

Spiegeln Sie die SSD nicht einfach, um Backups zu vermeiden. Redundanz kann Ausfallzeiten nach einem Geräteausfall verringern, schützt aber nicht vor einem fehlgeschlagenen Upgrade, versehentlichem Löschen, Datenbankbeschädigung oder dem Verlust des Hosts. Bewahren Sie versionierte Wiederherstellungspunkte auf und testen Sie die Wiederherstellung in einer isolierten Jellyfin-Instanz.

Verhindern Sie, dass I/O-intensive gemischte Aufgaben die Speicheraufteilung zunichtemachen

Die Aufteilung ist besonders sinnvoll, wenn I/O für den App-Zustand auf der SSD bleibt und große Medienübertragungen auf der HDD stattfinden. Backups, Downloads, Entpacken, Medienanalyse oder Transcode-Schreibvorgänge können diese Trennung zunichtemachen, wenn sie alle gleichzeitig auf dasselbe Gerät zugreifen. Legen Sie fest, wohin die einzelnen regelmäßig anfallenden Aufgaben schreiben, und planen Sie intensive Arbeiten bei Bedarf außerhalb der geschäftigsten Wiedergabezeiten ein.

Ein Homelab mit zwei Speicherebenen sollte mit derselben Art von gemischtem Random-I/O-Workload getestet werden, bei der Speicherwarteschlangen sichtbar werden. Die konkreten Benchmarkwerte lassen sich nicht direkt auf Jellyfin übertragen, wohl aber der zugrunde liegende Mechanismus: Gleichzeitige kleine Datenbankoperationen reagieren ganz anders auf Latenz als ein langer sequenzieller Medien-Lesevorgang.

Messen Sie Dashboard-Ladezeit, Suche, Wiedergabestart, Scan-Dauer, HDD-Warteschlangen und SSD-Latenz während einer normalen Überschneidung. Wenn das Durchsuchen schnell bleibt, die Wiedergabe aber nur auf das Hochdrehen der Festplatten wartet, funktioniert die Aufteilung wie vorgesehen. Werden beide Ebenen während eines Backups oder Imports langsamer, beheben Sie zuerst den gemeinsamen Controller-, Netzwerk- oder Planungsengpass, bevor Sie schnelleren Flash-Speicher kaufen.

Erweitern Sie die Ebene, die ihre Grenze tatsächlich erreicht

Erweitern Sie die SSD-Kapazität, wenn der App-Zustand von Jellyfin, Metadaten oder temporäre Dateien sich dem Grenzwert für freien Speicherplatz nähern oder eine weitere gemeinsam gehostete Datenbank dieselbe latenzarme Ebene benötigt. Erweitern Sie die HDD-Kapazität, wenn der Medienbestand die Kapazitätsgrenze des Verbunds erreicht. Rüsten Sie das Netzwerk nur dann auf, wenn der getrennte Medienpfad zum gemessenen Engpass wird.

Ein aktueller Leitfaden zu Speicherebenen für Medienserver unterscheidet die Workloads ebenso: SSD-Kapazität sollte latenzempfindliche Serverdaten bereitstellen, während HDD-Kapazität große Mediatheken speichert. Erweitern Sie die Ebene, deren gemessene Kapazitäts- oder Latenzgrenze tatsächlich erreicht wird.

Beenden Sie die Planung, wenn die SSD genügend Platz für den aktiven Arbeitssatz der Apps samt Wiederherstellungsreserve bietet, der HDD-Verbund den normalen Medienbedarf deckt, Backups beide Aufgaben angemessen abdecken und die stärkste übliche Überschneidung innerhalb der Latenzziele bleibt. Die Dual-Storage-Konfiguration ist erfolgreich, wenn jede Ebene eine klare Aufgabe hat - nicht, wenn an jedem verfügbaren Anschluss ein Laufwerk hängt.

NAS- und Servereinrichtung

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.