CCTV storage is usually specified by adding a number to a spreadsheet the week before the recorder is ordered. That number deserves more care. Retention failures are expensive to correct, and the calculation behind an adequate system is straightforward once the inputs are agreed. This guide covers the arithmetic and the assumptions that belong beside it.
The inputs that determine storage
Storage is a function of bitrate and time. Everything else in the calculation exists to establish bitrate. Resolution, frame rate, scene complexity, codec and encoder settings combine to produce the stream a camera actually sends, and that stream, multiplied by the number of cameras and the hours recorded, gives the daily volume. Getting those inputs wrong is the usual reason a storage estimate is out by a factor of two.
Write the assumptions down as part of the design. A statement that the system will retain thirty days at an average of two megabits per second across twenty-four cameras is verifiable; a statement that the recorder has eighty terabytes is not. When a camera is later upgraded to a higher resolution, the written basis makes it obvious that the calculation needs revisiting rather than guessing whether the recorder is still adequate.
Published bitrate tables are a starting point, not a measurement. Encoder settings, scene activity and firmware all shift the real figure, and the difference compounds across cameras and days. Recording a sample channel for twenty-four hours at the intended resolution and frame rate gives a number that can be defended, and it is a small effort compared with rebuilding a storage platform after go-live.
- Resolution and lens: a higher pixel count raises bitrate, especially where detail matters
- Frame rate: 12 to 15 frames per second suits most general surveillance
- Codec: H.265 typically reduces bitrate over H.264 at comparable image quality
- Scene complexity: busy entrances and night scenes with movement cost more bits
- Camera count and recording schedule: continuous against motion-triggered recording
- Retention period in days, and whether any channel needs to be kept longer
The numbers in the worked example below are generic and exist only to demonstrate the method. Take real bitrates from the equipment you intend to supply, measured on a sample channel, before a recorder is specified.
A worked calculation with generic assumptions
Take twenty-four cameras at 4MP, recording continuously at 15 frames per second with H.265, and an assumed average bitrate of 2 Mbps per camera. Convert bitrate to daily volume: 2 Mbps divided by 8 gives 0.25 megabytes per second, and multiplied by 86,400 seconds that is about 21.6 gigabytes per camera per day. Twenty-four cameras therefore produce roughly 518 gigabytes per day, or just over half a terabyte.
Multiply by the retention period. Thirty days at 518 gigabytes per day is about 15.5 terabytes of recorded data. Add headroom for file-system and index overhead, in the region of ten per cent, which brings the usable requirement to roughly 17 terabytes. That figure, not the raw multiplication, is what the recording platform must actually deliver, so it is the figure to carry into procurement.
RAID and usable capacity
Usable capacity is not raw capacity. A RAID 6 array across eight drives with two parity disks presents about seventy-five per cent of raw capacity to the system, so 17 terabytes usable needs roughly 23 terabytes of raw disks. RAID level, hot spares, drive sizing and rebuild time are design decisions with real consequences: RAID 5 tolerates a single drive failure, RAID 6 tolerates two, and larger drives lengthen rebuild times.
Recorders also impose their own limits. Some entry-level appliances cap the disk size they support, cap the number of channels per unit, or share throughput across recording and playback. A storage figure that is arithmetically correct can still exceed what the platform can address, which is why channel count, maximum disk size and throughput should be checked against the calculation rather than after delivery.
Bandwidth, and local versus cloud recording
Storage sizing is often mistaken for bandwidth sizing, and the two are different. Remote live viewing and playback consume upstream bandwidth: ten cameras viewed simultaneously at 2 Mbps require about 20 Mbps of sustained upstream capacity at the site. That figure rarely exists on a business broadband line, which is why recording should remain local and remote viewing should be sized for a smaller number of simultaneous streams.
Cloud recording shifts the storage decision without removing the requirement. The retention period still has to be paid for, the site still needs enough upstream bandwidth to send the video, and the recovery path for a lost connection has to be defined. Many UAE installations combine local recording for full retention with scheduled or event-based upload, which keeps bandwidth predictable while placing an off-site copy of the most important footage somewhere it can be reached.
Whatever method is used, the calculation should be rechecked whenever the system changes. An extra eight cameras, a move to 4K at an entrance, or a request to extend retention to sixty days all change the arithmetic, and each is cheaper to accommodate in a design review than in a storage upgrade after the recorder has already started overwriting.
Discuss a similar requirement