So wählen Sie SSD-, HDD- und Backup-Kapazität für Jellyfin aus

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 Choose SSD, HDD, and Backup Capacity for Jellyfin

Jellyfin-Speicher sollte als drei unterschiedliche Kapazitätsprobleme betrachtet werden: schneller Speicher für Anwendungen und temporäre Arbeitsdaten, kostengünstige Medienkapazität und unabhängige Wiederherstellungskapazität. Eine einzige sehr große Festplatte zu kaufen und sie als „Jellyfin-Speicher“ zu bezeichnen, erschwert die Einschätzung von Leistung, Wachstum und Wiederherstellung.

Beginnen Sie mit der aktuellen Bibliothek und den gemessenen Jellyfin-Daten, addieren Sie den größten temporären Arbeitsbedarf, prognostizieren Sie das Medienwachstum für den Nutzungszeitraum und dimensionieren Sie anschließend die Backup-Generationen außerhalb der Live-Fehlerdomäne. Verwenden Sie die nutzbare Kapazität nach der Redundanz statt der Rohwerte auf den Laufwerksetiketten.

SSD für App-Daten und temporäre Spitzen dimensionieren

Jellyfins Datenbank, Metadaten, Grafiken, Protokolle und andere Anwendungsdateien erzeugen zufällige I/O-Zugriffe, die von niedriger Latenz profitieren. Der Transkodierungs-Cache stellt eine andere temporäre Anforderung dar, die bei gleichzeitigen Konvertierungen stark anwachsen kann.

Die aktuellen Speicherempfehlungen für Jellyfin weisen darauf hin, dass eine mittelgroße Datenbank auf mehrere Dutzend Gigabyte anwachsen kann und ein Transkodierungsordner vorübergehend nahezu die Größe der Quelldateien erreichen kann, die gerade konvertiert werden. Dadurch wird eine kleine Boot-SSD riskant, selbst wenn die Datenbank heute noch klein ist.

Messen Sie die aktuelle Größe der Anwendungsdaten und den größten tatsächlich auftretenden Transkodierungsspitzenwert. Planen Sie zusätzlichen freien Speicher für Aktualisierungen, temporäre Dateien und Wachstum ein, statt die SSD bis zu ihrer angegebenen Kapazität zu füllen.

HDD-Kapazität anhand von Medienwachstum und nutzbarer Redundanz dimensionieren

Große Mediensammlungen profitieren normalerweise von Kapazität und sequenziellem Durchsatz. Berechnen Sie die aktuelle Mediengröße, realistische jährliche Neuzugänge und die Anzahl der Jahre, in denen Sie das Speicherlayout voraussichtlich nutzen werden, bevor Sie es neu aufbauen.

Wandeln Sie das prognostizierte Ziel anschließend in nutzbare Kapazität nach Abzug des Aufwands für Spiegelung oder Parität um. Zwei 12-TB-Laufwerke in einem Spiegel bieten keine 24 TB nutzbare Medienkapazität, und Snapshots oder reservierter freier Speicher können die Kapazität, die als sicher nutzbar gelten sollte, zusätzlich verringern.

Die Analyse von ZimaSpace zu Jellyfins Speicher-Overhead zusätzlich zu den Mediendateien unterstreicht diese Trennung: Persistente Anwendungsdaten, erzeugte Dateien, temporäre Transkodierungen und Quelldateien wachsen nicht nach derselben Kurve.

Medienkapazität für die Arbeitslast kaufen, nicht standardmäßig nach SSD-Geschwindigkeit

Bei großen Filmen und Episoden ist der sequenzielle Durchsatz normalerweise wichtiger als die SSD-Latenz. Mehrere unabhängige Streams und gleichzeitige Scans können den Suchaufwand erhöhen, doch ein gesunder HDD-Verbund kann weiterhin einen beträchtlichen Mediendurchsatz bereitstellen.

Bevorzugen Sie Laufwerksmodelle und Aufzeichnungstechnologien, die zu dauerhaften Server-Schreibvorgängen und einem planbaren Wiederaufbauverhalten passen. Verlagern Sie große Medienbestände nur dann auf SSDs, wenn Lautstärke, Baugröße, Stromverbrauch oder gemessenes Verhalten bei gemischten I/O-Zugriffen die deutlich höheren Kosten pro Terabyte rechtfertigen.

Die Medienebene sollte anhand der kombinierten Bitrate und des Wartungsaufwands ausgewählt werden, nicht aufgrund der pauschalen Behauptung, SSDs seien immer schneller.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Backup-Kapazität getrennt von RAID-Kapazität berechnen

RAID, Spiegelungen, ZFS-Redundanz oder Btrfs-Spiegel verbessern die Verfügbarkeit nach dem Ausfall bestimmter Laufwerke, bewahren jedoch keine gelöschten Metadaten, beschädigten Anwendungszustände, fehlerhaften Aktualisierungen, Ransomware-Schäden oder Administratorfehler.

Das 3-2-1-Modell empfiehlt mehrere Kopien auf unterschiedlichen Medien, wobei sich mindestens eine Kopie an einem anderen Standort befindet. Entscheiden Sie bei Jellyfin separat, ob unersetzliche Medien, ersetzbare gerippte Medien und der Anwendungsstatus dieselbe Backup-Tiefe benötigen.

Backups des Anwendungsstatus sind im Vergleich zu einem Medienarchiv im Multi-Terabyte-Bereich klein. Daher kann es wirtschaftlich sein, Benutzer, Wiedergabefortschritt, Metadaten und Konfiguration regelmäßig zu schützen, auch wenn für die vollständige Medienbibliothek eine andere Backup-Strategie gilt.

Vor der Bestellung von Laufwerken ein Kapazitäts-Arbeitsblatt verwenden

Speicherrolle	Zu messender Wert	Kapazitätsentscheidung
SSD für Anwendungsdaten	Aktuelle Daten + Wachstum	Persistenter Spielraum für niedrige Latenz
SSD für Transkodierungsdaten	Größte Datei × gleichzeitige Konvertierungen	Temporärer Spitzenbedarf + Freispeicherreserve
HDD für Medien	Aktuelle Bibliothek + jährliches Wachstum	Nutzbare Kapazität nach Redundanz
Lokales Backup	Geschützter Umfang × aufbewahrte Generationen	Unabhängige Kapazität für Wiederherstellungen
Offsite-Backup	Unersetzlicher Umfang + Aufbewahrung	Separate Kopie für die Notfallwiederherstellung

Kaufen Sie nicht alle drei Ebenen mit derselben Wachstumsrate. Berechnen Sie die Kapazität neu, nachdem Sie Trickplay aktiviert, die Backup-Aufbewahrung geändert, 4K-Remuxes hinzugefügt oder von überwiegend Direct Play auf häufiges Transkodieren umgestellt haben.

FAQ

Sollte die gesamte Jellyfin-Medienbibliothek auf einer SSD liegen?

Normalerweise nicht. SSDs sind für Jellyfins Anwendungsdaten und temporäre Pfade mit vielen zufälligen I/O-Zugriffen am wertvollsten. HDDs bleiben für große sequenzielle Medienzugriffe kostengünstig, wenn Gesamtdurchsatz und Suchverhalten zur tatsächlichen Stream-Mischung passen.

Wie viel Backup-Speicher benötigt Jellyfin?

Das hängt davon ab, was Sie schützen und wie viele Wiederherstellungspunkte Sie aufbewahren. Dimensionieren Sie das Backup des Anwendungsstatus getrennt vom Medienarchiv und multiplizieren Sie anschließend den geschützten Umfang mit einer realistischen Aufbewahrungsdauer, statt einfach die Rohkapazität des Speicherpools zu kopieren.