How big should your storage server be? Sizing for catch-up, VOD, tube and file hosting

Storage is the silent budget killer. Operators obsess over bandwidth, argue about CPU and GPU, then casually order "64 TB, that'll be plenty" — and six months later they're frantically migrating a hot library off a saturated RAID-6 array at 03:00 because catch-up has gone from "nice extra" to "the only reason subscribers stay."

This post is the napkin math we walk every prospect through before they buy a storage server. Same approach as our IPTV bandwidth post — four numbers decide whether a single 120 TB box is plenty or you're already cooked at sign-up.

The formula

Total storage you need at the head-end is roughly:

TB_usable = catalogue_hours × avg_bitrate_mbps × 3600 / 8 / 1_000_000 × redundancy_multiplier

…and the concurrent read budget your disks have to feed in parallel is:

read_Mbit/s = peak_concurrent_VOD_users × avg_bitrate_mbps × (1 − cache_hit_ratio)

Two numbers, four inputs each. Miss two of them and you're either paying for a petabyte you'll never fill or running at 95 % disk utilisation on a Saturday night with subscribers complaining that catch-up "stutters."

Let's pull each one apart.

1. Catalogue size — what actually lives on disk

The naive answer is "all the content I have." The real answer depends on what kind of operator you are:

For a typical mid-size IPTV operator with 400 channels × 14-day catch-up window × 5 Mbps avg bitrate:

400 × 14 × 24 × 3600 × 5 / 8 / 1_000_000 = 302 TB raw catch-up

Add a 20K-title VOD library at avg 1.5 GB per title (mixed SD/HD/H.264) and you've got another 30 TB on top, so roughly 330 TB raw before any RAID overhead.

For a tube site with 50K active uploads at avg 400 MB per video, retained 12 months: 20 TB raw. Easy.

For a file-hosting operator with 5K paid uploaders × 8 GB/month average upload × 6-month retention (paid users keep files, free users purge at 30 d): 240 TB active, 60–80 TB churned monthly.

2. Redundancy multiplier — what raw becomes usable

You're never running disks as JBOD. Pick the redundancy scheme and multiply:

For a 12-disk box of 18 TB HDDs (216 TB raw):

• RAID-6: 180 TB usable
• RAID-Z2 with 1 hot spare: ~162 TB usable
• 3× Ceph replicated: 72 TB usable but survives entire-node loss

Rule of thumb: RAID-6 / RAID-Z2 for HDD bulk storage. RAID-10 or RAID-Z2 of mirrors for NVMe hot tiers. Anything past 24 disks in a single vdev — you want Z3 or a clustered filesystem because rebuild times become a risk window of their own.

3. Concurrent read budget — the part everyone forgets

You can store a petabyte on a single 60-bay JBOD, but if your subscribers all hit it at the same time, the disks themselves become the bottleneck. Math:

peak_VOD_users × avg_bitrate × (1 − cache_hit) = read_Mbit/s the spinning disks must serve

Cache hit ratio depends entirely on workload skew:

For a 30K-active-line IPTV panel: peak concurrency 38 % = 11,400 boxes, average bitrate 5.2 Mbps. 5 % of those play catch-up instead of live = 570 concurrent VOD streams. With 80 % cache hit: 570 × 5.2 × 0.2 = 593 Mbps of actual disk read.

A modern 18 TB SATA HDD does ~250 MB/s sequential or roughly 2 Gbps sustained, assuming sequential reads on cached metadata. With random small-IO mixed in, real number is 600–800 Mbps per disk. So 593 Mbps fits on 1 disk in theory, on 2–3 disks in practice. You're not IOPS-bound at this scale.

Now compare a 200K-line OTT operator with 30 % VOD play rate and 50 % cache hit: 200K × 0.4 × 0.3 × 5.2 × 0.5 = 62.4 Gbps of disk read. Suddenly 18 TB HDDs at ~700 Mbps real-world each = you need 90+ HDDs in parallel just to feed read traffic, before storing a single byte. That's where the hot tier (NVMe cache) becomes mandatory — not optional.

4. Tier choice — HDD vs SSD vs NVMe

Per-TB pricing as of 2025–26 in our colos:

NVMe is roughly 15× the cost per TB of bulk HDD — but 25× the throughput per drive. So the call is always about IOPS density vs raw capacity. Don't put cold catch-up on NVMe. Don't try to serve 60 Gbps of concurrent VOD reads off a HDD-only pool.

Worked example: 30K-line panel, 14-day catch-up, 20K VOD titles

Inputs:

• 400 live channels, 14 days catch-up, 5 Mbps avg → 302 TB raw catch-up
• 20K VOD titles, avg 1.5 GB → 30 TB raw VOD
• Total raw library: 332 TB
• RAID-Z2 in 2× vdevs of 12 × 24 TB → 480 TB raw, 384 TB usable, fits with 13 % headroom
• Peak concurrent VOD users: 30K × 0.38 × 0.05 = 570
• Cache hit ratio: 80 % (top-channel skew)
• Disk read budget: 570 × 5.2 × 0.2 = 593 Mbps
• 2 % NVMe L2ARC = 8 TB across 2× 7.68 TB U.2 (mirrored, $44/month per TB of cache)

Single 24-bay storage box does this comfortably, room for growth to 18-month catch-up before needing a second chassis. Total monthly cost: ~$890–1,200 depending on PoP, ports and IP allocation.

Where smaller operators live

The wall most operators hit: they buy a 60 TB box at launch with no catch-up, add 7-day catch-up at month 6, and suddenly need 100 TB. The single-chassis upgrade path stops at around 200 TB usable for SATA-HDD pools — past that, planning for chassis #2 (and the network between them) is a separate architecture exercise, not a "just add disks" extension.

The catch-up problem nobody plans for

Catch-up is the most predictable storage growth pattern in IPTV:

• Operators add catch-up because subscribers ask for it
• Subscribers immediately want 7 → 14 → 30 days
• Every day of catch-up = ~22 TB raw for a 400-channel panel at 5 Mbps avg
• Going from 7-day to 30-day = ~500 TB raw delta
• That's an entire 36-bay chassis, just to extend the catch-up window

Plan your storage for the catch-up window you'll have in 18 months, not the one you launch with. The cost delta between buying a 24-bay box vs a 36-bay box at provisioning time is ~$80/month. The cost of migrating an in-production catch-up pool off a saturated 24-bay box at 03:00 is much higher than that.

File hosting & tube sites — the different problem

For file hosting (Rapidgator/Mega-style) and tube sites, the math flips:

• Library size is unbounded and grows linearly with paid users
• Read concurrency is lower (downloads are sequential and long, not interactive)
• Write throughput matters — uploads stream straight to disk
• Hot-cold tiering is brutal — 90 % of files get < 5 reads in their lifetime; 10 % get 1000+

For a tube site doing 800 GB/day of uploads, kept 12 months, that's 290 TB/year. A 60-bay JBOD with 24 TB disks gets you 18 months of growth. Plan a second chassis before the first is at 70 %.

For file hosting, the killer is upload bandwidth to disk — 100K free users uploading 200 MB chunks all weekend is a different IOPS pattern than VOD reads. NVMe write cache (1–2 TB, mirrored) absorbs the bursts and flushes to HDD pool overnight.

DDoS, drive failures, and the storage-server Monday

Real numbers from one of our customers (mid-size tube site, ~140 TB pool):

• Avg read traffic: 4.2 Gbps
• Black-Friday weekend peak: 13.8 Gbps
• One Saturday: 4× 18 TB drives failed within 6 hours of each other (same lot, same age) — RAID-Z2 survived with 2 hot spares, rebuild took 38 hours during which pool ran at 60 % normal IOPS. No subscribers noticed.
• DDoS attempt mid-week (140 Gbps SYN flood): our scrubbing absorbed it, storage box never saw degradation.

Disk failure rate on bulk HDD is ~2–4 % AFR. At 36 disks per box, expect 1 failure every 6–9 months as steady state. Plan for hot spares (2 per array minimum), have replacement disks at the PoP, and the rebuild window is just a thing that happens — not an outage.

What we sell, and why

Same as our other sizing posts — these numbers map directly to what we provision:

• Up to 80 TB: bare-metal storage server with 8× 8 TB or 4× 18 TB HDD, RAID-6, 1G or 10G port, from $239/mo.
• 80–300 TB: 12-bay or 24-bay chassis with NVMe L2ARC cache, 25G unmetered, from $389/mo.
• 300 TB – 1 PB: 36-bay HDD chassis or 2× chassis JBOD with mirrored NVMe metadata pool, 100G unmetered, from $890/mo.
• 1 PB+: clustered storage, Ceph or distributed pool, own AS announcement for routing flexibility, multi-PoP for edge replication.

Provisioning is hours for stock SKUs, 24–72 h for custom disk layouts (specific NVMe models, 30 TB+ drives, JBOD shelves). Talk to engineering if your spec doesn't fit a row above — most don't, and that's fine.

TL;DR

• Storage need = catalogue × bitrate × retention × redundancy. Catch-up is ~22 TB per day per 400 channels.
• Read budget = concurrent VOD users × bitrate × (1 − cache hit). 80 % cache hit on IPTV catch-up is typical.
• HDD pool + NVMe cache (2–5 %) covers 95 % of operator workloads.
• RAID-Z2 / RAID-6 for HDDs, 10 % spare hot, plan for rebuild windows not outages.
• Catch-up window grows by subscriber demand, not by your plan. Size for 18 months ahead.
• Buy chassis #2 before chassis #1 hits 70 % usable. Migration on full chassis is harder than ordering early.

If you're between rows in the table — a 100 TB tube site that wants to add live cams, a panel that wants to go from 7-day to 30-day catch-up, a file host trying to figure out write cache sizing — write us. We'll size it together, no upsell unless you actually need the bigger box.