How to Choose SSD, HDD, and Backup Capacity for Jellyfin

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

How to Choose SSD, HDD, and Backup Capacity for Jellyfin

Jellyfin storage should be purchased as three different capacity problems: fast application and scratch space, economical media capacity, and independent recovery capacity. Buying one very large drive and calling it “Jellyfin storage” makes it harder to predict performance, growth, and recovery.

Start with the current library and measured Jellyfin data, add the largest temporary working peak, project media growth for the ownership period, then size backup generations outside the live failure domain. Use usable capacity after redundancy rather than the raw numbers printed on drive labels.

Size the SSD for App Data and Temporary Peaks

Jellyfin's database, metadata, artwork, logs, and other application files create random I/O that benefits from low latency. Transcode cache creates a different temporary requirement that can spike during simultaneous conversions.

Current Jellyfin storage guidance notes that a moderate database can grow into tens of gigabytes and a transcode folder can temporarily approach the size of the source media being converted. That makes a tiny boot SSD risky even when the database itself is small today.

Measure current app-data size and the largest real transcode peak. Add free-space margin for updates, temporary files, and growth rather than filling the SSD to its advertised capacity.

Size HDD Capacity From Media Growth and Usable Redundancy

Bulk media normally favors capacity and sequential throughput. Calculate current media size, realistic annual additions, and the years you expect to keep the storage layout before rebuilding it.

Then convert the projected target into usable capacity after mirror or parity overhead. Two 12 TB drives in a mirror do not give 24 TB of usable media capacity, and snapshots or reserved free space can reduce what should be treated as safe working capacity further.

The ZimaSpace analysis of Jellyfin storage overhead beyond media files reinforces the separation: persistent app data, generated assets, temporary transcodes, and source media do not grow on the same curve.

Buy Media Capacity for the Workload, Not SSD Speed by Default

For large movies and episodes, sequential throughput is usually more important than SSD latency. Multiple independent streams and simultaneous scans can increase seek pressure, but a healthy HDD pool can still serve substantial media bandwidth.

Prefer drive models and recording technologies that fit sustained server writes and predictable rebuild behavior. Move bulk media to SSD only when silence, physical size, power, or measured mixed-I/O behavior justifies the much higher cost per terabyte.

The media tier should be chosen from the combined bitrate and maintenance workload, not from a generic claim that SSD is always faster.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

Calculate Backup Capacity Separately From RAID Capacity

RAID, mirrors, ZFS redundancy, or Btrfs mirrors improve availability after some drive failures, but they do not preserve deleted metadata, corrupted application state, a bad upgrade, ransomware damage, or an administrator mistake.

The 3-2-1 model recommends multiple copies across different media with at least one copy off-site. For Jellyfin, decide separately whether irreplaceable media, replaceable ripped media, and application state deserve the same backup depth.

Application-state backups are small compared with a multi-terabyte media archive, so protecting users, watch progress, metadata, and configuration frequently can be economical even when the full media library has a different backup strategy.

Use a Capacity Worksheet Before Ordering Drives

Storage role	Input to measure	Capacity decision
SSD app data	Current data + growth	Persistent low-latency headroom
SSD transcode scratch	Largest file × concurrent conversions	Temporary peak + free-space margin
HDD media	Current library + annual growth	Usable capacity after redundancy
Local backup	Protected scope × retained generations	Independent restore capacity
Off-site backup	Irreplaceable scope + retention	Separate disaster-recovery copy

Do not buy all three tiers at the same growth rate. Recalculate after enabling trickplay, changing backup retention, adding 4K remuxes, or moving from mostly Direct Play to frequent transcoding.

FAQ

Should the entire Jellyfin media library live on SSD?

Usually no. SSD is most valuable for Jellyfin app data and temporary random-I/O paths. HDD remains cost-effective for large sequential media reads when aggregate throughput and seek behavior meet the real stream mix.

How much backup space does Jellyfin need?

It depends on what you protect and how many recovery points you retain. Size application-state backup separately from the media archive, then multiply the protected scope by realistic retention rather than copying the raw storage-pool size.