CCTV Storage Sizing: Why 30 Days Isn't 30 Days

CCTV Storage Sizing: Why 30 Days Isn't 30 Days

Sizing CCTV storage is one formula: cameras × average bitrate × seconds per day × retention days ÷ 8. The arithmetic is trivial. The inputs are where systems fail — the average bitrate is never the number printed on the camera's config page, and a system contracted for 30 days of retention needs closer to 35 days of disk to actually deliver 30.

The gap between those two numbers is where most surveillance projects quietly break their own SLA. Nobody notices, because retention only gets audited on the day somebody asks for footage from three weeks ago.

What does the retention formula actually look like?

Work in bits, convert once at the end:

GB per camera per day = bitrate_Mbps × 86,400 ÷ 8 ÷ 1,000 TB for the site = GB/day × cameras × retention_days ÷ 1,000

A camera streaming a steady 4 Mbps writes 43.2 GB every day. That single number is worth memorizing, because it makes site-level estimates something you can do in your head on a walkthrough: 4 Mbps ≈ 43 GB/day ≈ 1.3 TB/month per camera.

Take a 24-camera site, 4 MP sensors, H.265, 15 fps, recording continuously. The proposal says 3 Mbps per camera and 30 days. Here is what each layer of honesty costs:

The proposal number and the working number differ by 72%. Both were computed with the same formula. Only the inputs changed.

Why isn't your average bitrate the number in the camera config?

Because that field is a ceiling, not an average. Modern cameras run variable bitrate with scene-adaptive compression, and the output tracks how much detail and noise the sensor is actually seeing.

Axis publishes measured examples for its Zipstream implementation that span almost two orders of magnitude: a well-lit scene with occasional motion drops 25%, a daytime overview with frequent slight motion drops 50%, a dark noisy scene with occasional motion drops 90%, and a night-mode scene with very infrequent motion drops 99.7% (Axis Zipstream white paper, July 2026).

Two consequences follow, and they point in opposite directions.

First, sizing from the configured maximum overspends, sometimes by double. Second — and this is the one that bites — sizing from a quiet week underspends, because the quiet week isn't the week you need. Noise raises bitrate. Rain raises bitrate. An IR-illuminated parking lot with insects crossing the beam at 2 a.m. raises bitrate all night, every night, on every camera facing outward.

The same Axis paper is blunt about the obvious shortcut: using constant bitrate as a storage reduction strategy is not recommended, because cameras forced to hold a CBR ceiling discard forensic detail exactly when the scene gets busy. CBR gives you a predictable disk and an unpredictable investigation.

The practical rule: never size from a config field. Record the site for seven days with the real scene, the real lighting, and the real night mode, then pull the actual bytes-written figure from the VMS and divide.

Does switching to H.265 or AV1 buy you more days?

If you are still on H.264, yes, and the win is large. If you are already on H.265, the next codec buys you almost nothing.

Axis measured AV1 against both in real surveillance scenes: 18% to 33% lower bitrate than H.264 depending on the scene, but only 0.04% to 5.8% lower than H.265 (AV1 codec in video surveillance, June 2026). AV1's real argument in this market is that it is royalty-free, not that it halves your array.

That distinction matters when a vendor proposes a camera refresh as a storage fix. Moving H.264 to H.265 across 24 cameras genuinely converts a 31 TB requirement into something near 16 TB. Moving H.265 to AV1 converts 31 TB into roughly 30 TB — a rounding error against the cost of new cameras. Buy AV1 hardware for the licensing position and the decode support, and size the disks as if the codec never changed.

Where do the missing days actually go?

Nominal capacity and delivered retention are separated by four subtractions, and every one of them is invisible on a purchase order:

Parity and formatting. A drive sold as 8 TB presents about 7.28 TiB, and an eight-bay RAID 6 gives back six drives of capacity, not eight. Nothing mysterious here — but proposals quoting "48 TB of storage" for a 40 TB requirement are quoting raw, and the array delivers about 43 TB before the VMS takes its cut.

VMS overhead. The recording database, motion metadata, analytics events and thumbnail index all live on the same volume in most mid-market NVRs, and most VMS platforms hold a free-space reserve to avoid writing a volume to zero. Budget 10%.

Retention timing. Recorders delete on their own schedule, in blocks, usually with a lag. A system holding exactly 30 days of capacity spends part of every month at 29 and change. Size for 35 when the contract says 30.

Motion-only recording. The most oversold saving in the industry. It works on a stairwell. It does not work on a loading bay, a lobby, or any camera whose scene includes a road — and when it fails to save what you assumed, it fails by filling the disk early and silently overwriting the far end of the retention window. If you record on motion, size for the worst realistic activity day, not the average one.

What fails before the disk fills up?

Two things, and both are usually left out of the design.

The drive's workload rating. Surveillance drives are rated for a specific volume of annual writes — the Seagate SkyHawk line is specified for 180 TB/year at a 20% duty cycle (SkyHawk datasheet). Convert that to a bitrate and it becomes an operational limit you can actually use: 180 TB/year is about 45 Mbps of sustained write, or roughly eleven cameras at 4 Mbps.

A single-drive NVR carrying 16 cameras at 4 Mbps writes 252 TB a year. That is 40% past the rating, continuously, for the life of the box. The drive will not fail on schedule — it will fail early, and it will fail in the month the scene got busy. Spreading the same load across an eight-drive array puts each drive near 47 TB/year, comfortably inside spec. Array width is a durability decision as much as a capacity one.

The array losing a member mid-retention. Backblaze's Q1 2026 Drive Stats put the fleet annualized failure rate at 1.24%, with 20 TB and larger drives at 0.85% across more than 86,000 units (Backblaze, Q1 2026). Those are good numbers per drive. Across an eight-drive array they compound to roughly a 6.6% chance of at least one failure per year — about one array in fifteen, annually, in a data centre with climate control and staff. A rooftop equipment room in Jakarta is not that.

Which is why a rebuild has to be part of the sizing conversation, not an incident to be discovered later. Recording continues during a rebuild, the array is slower and unprotected while it runs, and a full-height modern drive takes a long time to resilver under a live write load. This is the same argument as RAID is not a backup, applied to a system whose entire purpose is retaining data it can never regenerate.

How do you size it so the number holds?

Six steps, in order. Steps one and two are the ones usually skipped, and they are the two that determine whether the rest is arithmetic or fiction.

1. Measure, don't assume. Record the real site for seven days across a full day/night cycle, then read bytes written per camera from the VMS. Use the busiest day as your blended average, not the mean.
2. Write the retention target down as a contract term. Days, which cameras, and whether it is continuous or event-based. "30 days" with no scope means every camera at full frame rate, and that is how it will be audited.
3. Design for retention × 1.15. Thirty-five days of capacity for a 30-day promise. This absorbs overwrite lag, 31-day months, and a seasonal bitrate rise without a purchase order.
4. Check the workload rating per drive, not per array. Aggregate Mbps ÷ number of data drives, converted to TB/year, must sit inside the drive's specification with room to spare.
5. Set per-camera retention where the VMS supports it. A lobby camera and a cash-handling camera rarely need the same window. Differentiated retention is the only storage saving that costs nothing in forensic value.
6. Monitor the delivered retention, not the disk percentage. Disk usage on a surveillance array sits at 95%+ forever by design — it tells you nothing. Query the VMS for the oldest available recording per camera, daily, and alert when any camera's window drops below target. That check belongs alongside the camera health polling described in SNMP for CCTV fleets.

That last one is the whole discipline in a single metric. Every other number in this article is a prediction; the oldest available recording per camera is a measurement. It is the only figure that answers the question the system exists to answer, and it costs one scheduled query a day to know.

Storage sizing done properly is not about buying more disk. It is about the gap between what a system promises and what it delivers being a number somebody watches — before the day it matters, not on it.