Storage math: how many terabytes do you actually need?

Video storage sizing has a reputation for being complicated. It is not. The arithmetic fits on one line and has not changed in twenty years. What makes storage quotes wrong is a single input that almost everyone guesses, and six adjustments that almost everyone skips.

The one line you need

Everything starts from converting a bitrate into a volume. A stream of one megabit per second, running continuously, produces:

Commit “10.8 gigabytes per day per megabit per second” to memory and you can sanity-check any storage proposal in your head, in a meeting, while the person presenting it is still talking. Twenty cameras at 4 Mbps for 30 days: 20 × 4 × 10.8 × 30 = 25,920 GB, call it 26 TB before adjustments. If the quote in front of you says 8 TB, somebody has assumed motion recording, a much lower bitrate, or both — and it is worth finding out which.

Note the units. Drive manufacturers sell terabytes as powers of ten, operating systems frequently report in powers of two, and the gap is about nine per cent. It is not the largest error in this calculation, but it is a free one to avoid: size in the manufacturer’s units and then subtract, rather than arguing about it later.

The number everybody guesses

Cameras and days are facts. Bitrate is an estimate, and it is where the whole calculation lives or dies. A single camera model, at fixed settings, will produce wildly different data volumes depending on what it is looking at:

• A still corridor with a closed door at the end compresses to very little. Frame after frame is nearly identical, which is exactly the case modern codecs are built for.
• A car park with trees, rain, headlights and a flag produces a great deal of data, continuously, because almost every pixel changes between frames.
• The same scene at night, with the camera pushing gain to see, produces sensor noise — which the codec cannot distinguish from detail and faithfully encodes. Night bitrates on a noisy camera routinely exceed daytime ones.

H.265 and the various smart or adaptive codecs widen that spread rather than narrowing it. On a static scene they can cut the data enormously; on a busy one the saving is modest. A quote built on a single “average” bitrate across a mixed site is therefore not wrong so much as unlikely to be right.

Two ways to do better. If the site exists, record a representative camera for twenty-four hours on the real scene with the real settings, and read the actual figure off the recorder. If it does not, model a range — a low case and a high case — and size to the high case for the cameras that matter. Either approach beats a number typed in from a datasheet.

Six adjustments to the raw figure

1. Recording mode. Continuous recording is predictable and easy to defend. Motion or event recording looks like a fifty per cent saving on paper and behaves unpredictably in practice — a busy dock can trigger nearly continuously, which means you get the cost of motion recording and the storage of continuous.
2. Parity and file system. Protected arrays spend capacity on redundancy, and file systems take their own overhead. Always size on usable capacity. A twelve-bay chassis of 20 TB drives is not 240 usable terabytes.
3. Headroom. Recorders behave badly when they are completely full, and overwrite behaviour at the edge is rarely the thing you wanted. Leave a margin.
4. Second streams and audio. A lower-resolution substream for remote viewing and mobile clients is common, useful, and additional. Audio is small per channel and not zero.
5. Protected clips. Footage locked against overwrite for an investigation or a claim accumulates outside your retention window. Over a few years this quietly consumes real capacity, and nobody is watching it.
6. Growth. Systems gain cameras. A chassis sized exactly right on day one is short by year two, and expansion after the fact costs more than the bays would have. Size the enclosure for where the system is going, even if you populate the drives later.

A worked example

A distribution warehouse: 36 cameras, 30 days retention, continuous recording. Twelve interior cameras on quiet aisles, sixteen on the dock and floor, eight outdoors covering the yard.

Two things are worth noticing. The eight exterior cameras consume as much storage as the sixteen interior ones on the floor, because outdoor scenes move constantly — which means the cheapest way to reduce storage on this site is to think hard about the exterior cameras’ frame rate and field of view, not about the interior ones. And the raw number is only the beginning; how far above it you specify is a judgement about the adjustments above, made explicitly rather than by rounding up and hoping.

Reading a recorder quote

Five questions expose most of the difference between two storage proposals:

1. Is the quoted capacity raw or usable? This alone accounts for a large share of the gap between two quotes for the same system.
2. What bitrate and recording mode were assumed, per camera? If the answer is a single figure across a mixed site, the estimate has not been done.
3. What happens when the array fills? Oldest-first overwrite is normal; confirm it, and confirm what happens to protected clips.
4. What is the rebuild time on a drive failure, and is there a spare? A large array rebuilding for days while unprotected is a real risk, not a theoretical one.
5. Is the retention figure contractual? If regulation, an insurer or a customer contract sets your retention, the recorder has to meet it on the worst day of the year, not on the average one.

The last question is the one that most often changes the design. Plenty of organisations pick thirty days out of habit, and plenty of others are bound to a number they have never checked. Find out which you are before you size anything — it is the cheapest decision in the whole exercise.

The pixel-density side of the same design sits in Pixels per foot, and the wider background is in Storage sizing and IP video 101.