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

Size CCTV storage from the camera count, measured average bitrate, recording hours, and retention target. Then allow for recorder overhead and realistic peaks. This article uses a 35-day capacity example for a 30-day promise; that margin is a design assumption to test, not a universal requirement.

A gap between assumed and measured inputs can make a surveillance system miss its retention target. 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 cited tests found much smaller gains from AV1.

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. Do not assume H.264-to-H.265 migration always halves storage. Measure your scenes again at comparable image quality. The cited Axis tests found relatively small H.265-to-AV1 savings; test your own site before using those numbers to justify a camera replacement. 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 capacity units. Eight 8 TB drives provide 64 TB raw. RAID 6 leaves six drives of capacity: 48 TB, or approximately 43.7 TiB. TB is decimal and TiB binary; the display conversion is not formatting loss. After an illustrative 10% reserve, about 43.2 TB or 39.3 TiB remains, before any further overhead not already counted. State units in the proposal rather than comparing a 40 TB requirement with a TiB display.

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. The 10% allowance above is illustrative; check the reserve and overhead required by the actual VMS and filesystem.

Retention timing. A recorder may delete in blocks and reserve free space. A 15% margin on 30 days gives 34.5 days, rounded to 35 in this example. Test that starting assumption against the recorder. Rolling 30-day retention does not change because a calendar month has 31 days.

Motion-only recording. The most oversold saving in the industry. It may save substantially in a quiet stairwell, but much less on a busy loading bay, lobby, or road-facing scene — 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 about 252 TB a year, around 40% above an illustrative 180 TB/year rating. That supports changing drive class or distributing load, not predicting a failure date. Check whether the model rating counts reads as well as writes. RAID calculations also need parity writes, playback, and rebuild traffic; simply dividing by drive count does not capture all of them.

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). For illustration only, assuming each drive has an independent 0.85% annual failure probability gives 1 − (1 − 0.0085)^8, or about 6.6%, for at least one failure across eight drives. Backblaze annualized failure rates are not directly transferable probabilities for every CCTV drive. Age, temperature, model, and shared failures change site risk.

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 may slow down and has reduced redundancy while it runs. RAID 6 with one failed drive still tolerates one further drive failure, and a high-capacity 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 measured day as a conservative sizing input and check whether the week represents seasonal or event peaks.
2. Write the retention target down as a contract term. Days, which cameras, and whether it is continuous or event-based. A bare "30 days" promise leaves camera coverage, quality, and recording mode ambiguous.
3. Test a capacity margin. Retention × 1.15 gives 34.5 days, rounded to 35 in this example. Adjust for measured deletion patterns, bitrate peaks, and VMS free-space requirements.
4. Check per-drive workload, including reads, parity writes, and rebuild traffic. Match the drive and controller specifications with headroom.
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 can save space where evidence needs and retention policies actually differ.
6. Monitor the delivered retention, not the disk percentage. A rolling-retention array may stay at 95%+ usage by design. Usage remains useful for capacity alarms but does not establish the number of retained days. 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.