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.
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.
Aanbevolen producten
Koopgids
Meer om te lezen
How to Choose a Home Server for Jellyfin and Kodi
Kodi can reduce Jellyfin transcode demand when clients Direct Play well, so size the server from fallback conversion, storage, network, and shared services.
Before Buying a Jellyfin Server: Can Your Old PC Pass the Workload?
Reuse an old PC only after it passes the real Jellyfin workload, power, noise, storage, and recovery checks a new server would need to...
Hoe je drie of meer kandidaten voor een Jellyfin-server vergelijkt zonder achter specificaties aan te jagen
Sluit eerst Jellyfin-kandidaten uit die de werklast niet aankunnen en vergelijk daarna alleen de specificaties die de beslissing beïnvloeden, de eigendomskosten en het herstelvermogen...
