What is the basic CCTV storage formula?
CCTV video capacity is recorded bitrate multiplied by recording duration and camera count. Calculate each camera group separately when its settings or retention requirements differ, then add the results.
Bitrate is the amount of data a camera produces each second. Manufacturers commonly express it in megabits per second, written Mbps. Disk labels use bytes. Keep the units straight: eight bits make one byte.
For continuous recording at a stated average bitrate, use this decimal-unit formula:
Storage in TB = Mbps × 3,600 × recording hours per day × retention days × cameras ÷ 8 ÷ 1,000,000.
The factor 3,600 converts hours to seconds. Dividing by eight converts megabits to megabytes, and dividing by one million converts megabytes to decimal terabytes. That gives the size of the assumed recorded stream. You still need to account for how the recorder uses its disks before ordering them.
If cameras use different bitrates, calculate the sum of their individual rates first. Our CCTV and AI surveillance service starts by asking what each camera must show and how long that footage must remain available. The disk calculation follows those answers.
What does a fully worked calculation look like?
An illustrative system with 16 cameras averaging 4 Mbps each, recording continuously for 24 hours daily over 30 days, needs 20.736 TB for the assumed video streams. This is a worked example. Neither the bitrate nor the retention period is a recommendation for your site.
Start with one camera. At 4 megabits per second, dividing by eight gives 0.5 megabytes per second. Multiplying by 3,600 seconds gives 1,800 MB per hour. Over 24 hours, that becomes 43,200 MB, or 43.2 GB, per camera per day.
For 30 days, one camera needs 1,296 GB, or 1.296 TB. Multiplying by 16 cameras gives 20.736 TB. Here is the arithmetic in one line:
4 × 3,600 × 24 × 30 × 16 ÷ 8 ÷ 1,000,000 = 20.736 TB.
This example assumes every camera averages the stated bitrate throughout the period. It excludes audio, metadata, filesystem requirements and disk protection. If another camera group records at a different rate or for different hours, calculate that group separately rather than applying the same average without evidence.
A recorder may display capacity in binary units such as TiB, while a disk label uses decimal TB. Those units describe different byte quantities. Compare capacities in a consistent unit before deciding that a recorder has lost storage or that an array is too small.
Which camera settings change the recorded bitrate?
Resolution, frame rate, codec and scene complexity all affect the bitrate needed for useful evidence. The recorded stream settings matter more to capacity planning than the camera’s maximum specification on its box.
| Factor | Effect on storage planning | What to check |
|---|---|---|
| Resolution | More image detail can require more data | Recorded stream resolution and required subject detail |
| Frame rate | More frames can increase encoded data | Speed of relevant movement and playback usefulness |
| Codec | Compression method changes required bitrate | Camera, recorder and export compatibility |
| Scene activity | Movement and image noise can raise variable bitrate | Busy periods, night scenes and lighting changes |
| Bitrate mode | Fixed limits trade capacity predictability against quality | Constant or variable mode and configured limits |
| Recording schedule | Fewer recorded hours reduce retained data | Actual schedule, event buffers and policy |
| Audio and metadata | Additional streams consume capacity | Enabled channels and analytics data |
H.264 and H.265 are video compression standards. H.265 can use less data for comparable visual quality under suitable conditions, but the saving varies with the implementation and scene. Confirm decoding support on the recorder and the machines used to review exports. Avoid a blanket saving across the camera list. A quiet corridor and a busy entrance need separate measurements.
A lower frame rate may be suitable for a quiet doorway but inadequate for fast activity where intermediate movement matters. A strict bitrate ceiling can cause compression artifacts during busy scenes. Decide what you must be able to see after an incident. Cutting the bitrate to fit the disks is no saving if the useful detail disappears.
How should scene activity and smart codecs be measured?
Measure representative footage from each scene type, including busy and low-light periods. Use savings measured with your camera settings and scene activity. A best-case headline is a poor input for a disk order.
Variable bitrate lets the encoder use more data when the image is harder to describe. Traffic, foliage, rain and digital noise can increase that demand. Check after dark as well. A scene can look still yet produce plenty of data when poor lighting creates image noise. Improving illumination or adjusting image settings can sometimes help more than increasing storage alone.
Smart codecs use techniques such as longer intervals between full reference frames or different compression for less important areas. These techniques can reduce storage, but they may affect seeking through footage, motion detail or compatibility with export tools. Try finding and exporting a clip. A clear live view does not test those steps.
Collect recording statistics over a period that includes the operating conditions relevant to the site. Compare average consumption with high-activity periods and check whether the configured maximum bitrate is being reached. Document any scenes the sample did not capture, such as seasonal weather, special events or a full production shift.
When is motion-only recording a reasonable choice?
Motion-only recording is reasonable when gaps between events are acceptable and detection has been tested for the scene. There is no fixed storage saving to apply. The gaps also mean you do not get the same evidence coverage as continuous recording.
An event recorder saves footage when a detection rule triggers. Pre-event and post-event buffers retain time before and after the trigger, helping show context. Include those buffers in the estimate because frequent or overlapping events can make recording nearly continuous.
AI analytics may distinguish people or vehicles from other movement, depending on the system and configuration. That can make events easier to find, but a missed classification must not silently remove evidence the business needs. Test edge cases such as partial views, crowded entrances and poor lighting.
Some sites use continuous recording for a baseline and analytics to mark searchable events. Others retain selected streams only when activity occurs. Compare the operational consequence of a missed event before choosing between them. Set the recording policy first. Then work out how much disk space it takes.
How much space do RAID and recorder overhead require?
Disk protection and recorder overhead reduce the capacity available for retained footage. Work out how much usable array capacity the footage takes, then calculate the raw disks for the chosen layout.
RAID combines disks to provide a particular balance of capacity and tolerance of disk failure. Mirroring stores duplicate data; parity layouts reserve capacity for recovery information. The exact usable capacity depends on the layout, disk count, disk sizes and recorder support. Count a configured hot spare separately. It takes a drive bay but adds no normal recording capacity.
Do not apply a generic overhead percentage to every recorder. Check the manufacturer’s capacity calculation, supported disk models and limits. Account for formatting, metadata, reserved space and the recorder’s overwrite behavior. Leave room for bitrate variation and agreed growth. Write down why you chose that allowance so a later installer does not mistake it for unused capacity.
RAID is not an independent backup. Accidental deletion, theft, recorder failure or damage to the premises can affect the whole array. Also check rebuild behavior and sustained write performance: an array that holds enough bytes may still struggle to record every stream during a disk rebuild.
How should retention and cloud backup be chosen?
Retention should follow a documented operational and legal purpose, with authorized access and deletion rules. Cloud backup is useful for selected important clips when losing the local recorder would otherwise destroy the only copy.
Define who can request footage, who can export it and how an incident changes the normal deletion schedule. Confirm applicable privacy requirements with the appropriate adviser or authority. More drive bays are not a reason to keep everything indefinitely.
Off-site clip backup can protect incident evidence without uploading every camera continuously. Consider upload bandwidth, encryption, access logs, storage location and retrieval costs. Test playback from the exported copy, including timestamps and any required viewing software. If full continuous cloud recording is proposed, model sustained upload traffic and behavior when connectivity fails.
What should be checked before ordering disks?
Order disks after validating the inputs and the recorder’s supported configuration. Check what the cameras actually record before trusting the spreadsheet. A correct formula with the wrong bitrate still produces the wrong disk order.
- Group cameras by recorded bitrate, schedule and retention policy.
- Measure representative scenes, including low light and high activity.
- Calculate video capacity with explicit units and add enabled audio or metadata.
- Confirm usable RAID capacity, supported drives and write performance.
- Define headroom, overwrite rules, failure alerts and incident exports.
- Test retrieval and verify actual retained days after commissioning.
Discuss the result through our surveillance planning service. Send the camera count, recording settings and retention requirement through the contact form so we can check whether the proposed disks will retain the footage you expect.
