How to Size NVR Hard Drives Without Guessing (Retention Math That Holds Up)

How to Size NVR Hard Drives Without Guessing (Retention Math That Holds Up)

Every integrator has a storage-sizing story with the same shape: the calculator said 30 days, the customer signed for 30 days, and the recorder holds 16. The math wasn't wrong — the inputs were fiction. Storage sizing is the rare part of surveillance design that is genuinely just arithmetic, four numbers multiplied together, and it still misses by 2x on real sites because three of the four numbers get pulled from a brochure instead of a bench. This post is the sizing method I actually use: the four inputs, where each one lies to you, a worked 16-camera example you can adapt in a spreadsheet in ten minutes, and the overheads — RAID, file system, growth — that turn a "correct" drive count into a wrong one.

Why NVR Storage Estimates Miss by 2x

The failure mode is systematic, not random: estimates miss low, and they miss low because every convenient default is optimistic. The vendor calculator defaults to the codec's best-case bitrate — a daytime, low-motion, well-lit scene. The camera's own "target bitrate" setting is an average the encoder is allowed to exceed under VBR when the scene demands it. Night doesn't appear in the math at all, even though IR noise routinely doubles bitrate for a third of every day. And the person running the calculator is quoting a competitive job, so every judgment call rounds down. I audited a car dealership last year that was sold 30-day retention on numbers like these: the calculator assumed 2 Mbps per 4MP camera, the fleet actually averaged 5.1 Mbps across day and night, and the recorder was overwriting at day 12 — discovered, naturally, when a hit-and-run from day 14 was requested and gone. Nothing in that failure was exotic. The calculator was fine; the 2 Mbps was a wish. The method below exists to replace wishes with measurements.

The Four Inputs That Matter

Retention storage is exactly this: storage = bitrate × time × cameras × recording duty. Four inputs, four honesty checks.

Bitrate — per camera, in Mbps, as a 24-hour weighted average including night. This is the input that lies the most; it gets its own section below.

Time — retention days, from the contract. The one honest input, because someone else wrote it down. Just confirm whether it means calendar days of coverage (any gap is a breach) or "oldest recording available," which tolerates overwrites of low-priority streams.

Cameras — count the streams, not the devices. A four-head multi-sensor is four streams; a camera recording a secondary sub-stream for mobile or analytics adds that stream's bitrate too. Recorders that keep a stitched panoramic alongside the individual heads are storing a fifth stream nobody counted.

Recording duty — the fraction of time each stream actually writes. Continuous is 1.0 and is what I spec for anything evidentiary. Motion-based recording looks like a 40–70% saving on paper, but be honest about the scene: a lobby with a door in frame, a lot with a busy street at the edge, anything outdoors with foliage — those trigger 60–90% of the time at night sensitivity settings, and the pre/post-event padding (5–10 seconds each side, per event) erodes the saving further. If the retention promise is contractual, I size at continuous and let motion recording deliver bonus retention rather than promised retention.

Bitrate Honesty: H.265, Motion, and Scene Complexity

Codec first: H.265 genuinely delivers something like 30–50% savings over H.264 at the same quality, and smart-codec variants (Zipstream, WiseStream, and equivalents) add real further savings on static scenes. Take the savings — but measure them on your scenes, because all of these technologies save the most exactly where nothing is happening, and your liability scenes are the ones where things happen. A 4MP camera on H.265 with smart codec might sit at 1.5 Mbps watching an empty corridor and hold 6–8 Mbps watching a rainy IR-lit parking entrance at night. Both numbers are "the bitrate of a 4MP camera." Planning rules I use when I can't pre-measure: 4MP H.265 mixed indoor scenes, 3–4 Mbps weighted average; outdoor with IR and weather exposure, 4–6 Mbps; add 30–50% to any smart-codec demo number for night; and never carry a fleet average below 3 Mbps for 4MP into a contract without measured data behind it. When you can pre-measure — and on any site with an existing VMS you can — pull per-camera average and peak bitrate over a full week from the recorder's own statistics and use those. One week of real data beats every calculator ever shipped, and it's free.

Worked Example: 16 Cameras, 30 Days

A realistic mid-size job: 16 streams, all 4MP H.265 continuous recording, 30-day contractual retention. Ten indoor cameras at an honest 3 Mbps weighted average; six outdoor (entrances, lot) at 5 Mbps to cover IR nights and weather.

Note what that last line says: the job needs ~27 TB usable, and usable is not raw. Six 8TB surveillance drives give 48 TB raw; dual parity (RAID 6) consumes two members, leaving 32 TB usable — which lands this design with real margin. Run that raw-versus-usable conversion explicitly, every time: it's the single most common place a "correct" calculation turns into an undersized purchase order. (Four 8TB drives in RAID 6, by contrast, leave only 16 TB usable — a chassis that "holds 32 TB" and still misses the target.)

Surveillance-Rated vs Desktop Drives

The drive class question costs a few dollars per terabyte and decides how the array behaves for five years. Surveillance-rated drives (WD Purple, Seagate SkyHawk, and the enterprise capacity lines above them) differ from desktop drives in ways that map directly onto this workload: firmware tuned for continuous streaming writes rather than bursty desktop I/O; a rated workload of 180 TB/year and up versus a desktop drive's ~55 TB/year — and note that the 16-camera example above writes ~648 GB/day, which is ~30 TB/year per drive across six spindles even before rebuild traffic, so a desktop drive's rating is not comfortably distant; time-limited error recovery, so a marginal sector reports quickly to the RAID controller instead of hanging the array; and rotational-vibration compensation for multi-bay chassis, where eight spindles' worth of vibration measurably degrades an unprotected drive's throughput. Mixed fleets are the quiet failure: standardize the drive model in the design document and hold warranty replacements to it. The hard drive buying guide walks the class distinctions and the current capacity sweet spots in detail, and the NVR drive catalog carries the surveillance-rated lines this math assumes.

RAID Overhead Nobody Budgets

Redundancy is where sizing math goes to die quietly, because every overhead compounds against the retention target. Dual parity (RAID 6 or equivalent — which is what I spec for members above ~8TB, given multi-day rebuild windows and batch-correlated failures) costs two members per group: on a six-bay group that's 33% of raw capacity, on eight bays it's 25%. A hot spare, if you carry one in-chassis, is another member producing zero capacity. File-system formatting and the recorder's database and indexing take their cut — the ~10% in the worked example is a fair planning number. And remember that during a rebuild the array's effective write throughput drops hard; a design that needs every spindle at full health to keep up with the fleet's write rate will gap recordings for the multi-day duration of every rebuild. Sequence the design in this order: retention math gives usable TB → add overheads → choose RAID level and bay count → then pick member size, favoring more, smaller members over fewer giants for rebuild behavior. Running it backwards — "the chassis has 8 bays, the biggest drive is 20 TB, therefore we have plenty" — is how sites end up with 160 TB raw and 14 days of retention they can prove.

Growth Headroom Rules

The 25% headroom line in the worked example isn't padding; it's a forecast of things that reliably happen. Cameras get added — nearly every site I've serviced grew its camera count within three years, and the recorder purchased with zero headroom converts each added camera into an unbudgeted storage project. Resolutions creep up at refresh: a 4MP-to-8MP swap on even a quarter of the fleet moves the daily write rate substantially. Retention requirements ratchet — insurers, corporate counsel, and franchise standards revise upward, not downward. And bitrates drift up in place, as firmware updates re-tune encoders and as aging outdoor cameras develop noisier night images that compress worse. My working rules: 25% minimum headroom on any new design; 40% if the customer has told you expansion is coming; and put the projected fill date in the design document — "at contracted retention and current fleet, this array is full-capacity with headroom exhausted in year four" — so the mid-life expansion is a planned line item instead of a surprise. Headroom is also the cheapest it will ever be on the original PO: adding two more bays' worth of drives at build time costs hardware; adding them in year three costs hardware plus a migration window plus a service visit.

Where This Fits in a Deployment Program

Storage sizing is the load-bearing calculation of the whole recording tier: the bitrate honesty feeds it, the RAID and drive-class decisions inherit from it, and the retention promise in the contract is only as real as the arithmetic underneath. Done this way, it also becomes a sales asset — walking a customer through measured bitrates and a visible headroom line wins against a competitor's suspiciously small drive count, because the customer can see whose 30 days will still be 30 days in year three. Build the worked-example spreadsheet once, keep the honest bitrate table current from your own fleet's measurements, and every future quote takes ten minutes and survives an audit. When you're turning the math into hardware, the NVR hard drive range covers the surveillance-rated capacities, the buying guide covers the class and capacity trade-offs, and the commercial NVR roundup is the place to start when the recorder itself is also on the table. And if you've got a camera schedule and a retention target and want the sizing checked before the PO goes out, send the details over — a second pass on this math is fast, and it's a lot cheaper than explaining day 12.