How much storage does a business CCTV system need?

Use bitrate, not megapixels alone

Storage is driven by the amount of video data recorded over time. Camera count, average bitrate, recording hours and retention are the core inputs. Resolution affects the design but does not supply a reliable storage figure by itself. Two cameras with the same megapixel count can produce different bitrates because their scenes, motion, settings and compression differ.

Use measured recording data when expanding an existing system. For a new system, ask the supplier to state an average bitrate assumption per camera and validate it after installation. Axis's compression and rate-control documentation explains why bitrate control and scene conditions matter. Do not assume a maximum configured bitrate is always the measured average.

The decimal calculation

For decimal units, storage in TB equals cameras × Mbps × 1,000,000 × 3,600 × recording hours per day × days, divided by 8 and then by 1,000,000,000,000. The division by eight converts bits to bytes. Decimal TB, as used on drive labels, differs from binary capacity displays, so apparent figures may not match exactly.

For example, eight cameras averaging 4 Mbps, recording 24 hours a day for 30 days, generate approximately 10.37 TB of video. This is a mathematical example, not a claim that all eight-megapixel cameras use 4 Mbps. Add any other recorded streams or audio where applicable and allow for the system's usable capacity and overhead.

Distinguish raw and usable capacity

A recorder with nominal drive capacity does not necessarily make every byte available for video. Formatting, system use, reserved space and RAID design can reduce usable capacity. RAID can improve availability under some drive failures, but it is not the same as a separate backup of important footage.

Ask the supplier for usable recording capacity after the proposed configuration, not just the sum of the drive labels. Confirm the supported drive sizes, number of bays, compatibility and expected overwrite policy for the exact recorder. Allow room for changed settings, additional cameras and observed variation. There is no universal percentage that guarantees a chosen retention period in every system.

Treat motion savings as an assumption

Recording only selected events can reduce stored hours, but the saving depends on actual activity and reliable event detection. A busy entrance may trigger most of the day; trees, rain or insects can add events. Missing a detection can also mean missing the required recording. Do not apply an unexplained 80% saving to make a small drive appear sufficient.

If motion recording is proposed, write the assumed recorded share explicitly and test it at the real site. Include pre-event and post-event recording. Ask whether continuous low-rate recording plus event-quality footage is available and appropriate, but verify exact model support. Compare the operational risk of a missed event with the cost of larger storage.

Check image usefulness while adjusting settings

Lowering bitrate, frame rate or resolution may extend retention, but can reduce useful detail or motion capture. Excessive compression can make a face or action harder to interpret. Judge exported footage, not only the live view on a small tile. Live streams and recorded streams may have different settings.

Test busy and quiet scenes, day and night. Night noise and changing illumination can affect compression demand. Record the approved settings and use the same basis for the storage calculation. If a supplier promises a retention target, ask how it will be verified and what happens if actual measured bitrate is higher than the assumption.

Keep a practical decision record

Keep a capacity record showing assumptions, configured settings, drive arrangement and observed retention. Compare the estimate with actual recording after a representative period and investigate differences before changing quality. If storage falls short, identify whether the cause is more activity, another stream, a failed drive or an incorrect assumption. A larger disk can be the right solution, but reducing image usefulness to match an optimistic original quote is not an equivalent outcome. Record approved changes so the next retention review is based on the configuration actually running.

Monitor after commissioning

Check the oldest accessible recording after the system has run long enough, confirm that every camera is recording and verify that overwrite is operating as intended. Look for gaps, wrong time settings or drive warnings. A calendar showing dates is not proof that every expected clip exists.

Use the storage estimator to compare continuous and explicitly assumed event recording. Record the result as an estimate until actual retention is observed. Keep important incident exports separately through an authorised process before they are overwritten. Retention should be chosen for the business purpose and applicable obligations, rather than maximised without considering cost, access and privacy.