How Much Storage Do 40 Cameras Need? A Worked Answer, With Sources

"How much storage do I need for forty cameras?" is the most common sizing question in CCTV, and almost every answer to it is a single number. That is the problem. Size the same forty cameras two defensible ways and you get 12.7 TB and 36.9 TB. Both are arithmetically correct. The gap between them is larger than most people's entire estimate.

This article shows the arithmetic, sources the inputs, and is explicit about which numbers are measured and which are assumptions. It also corrects three rules of thumb that are repeated constantly in this industry and are measurably wrong.

The formula, with the units right

Bitrate is measured in bits per second. Storage is measured in bytes. The divisor is 8, and camera bitrates are decimal — 1 Mbit/s means 1,000,000 bits, not 1,048,576.

For one camera recording continuously:

bytes/second = R × 1,000,000 / 8   = R × 125,000
bytes/hour   = R × 450,000,000
bytes/day    = R × 10,800,000,000
bytes/period = R × 10,800,000,000 × days

Which collapses to three numbers worth remembering:

One Mbit/s, continuous	Storage
per hour	450 MB
per day	10.8 GB
per 30 days	324 GB

For a multi-camera estate, sum the bitrates first, then multiply once. If recording is not 24/7, scale by hours recorded over 24.

And if audio is enabled it is not free. Bosch specifies AAC-LC options at 48 and 80 kbps; at 80 kbps that is 0.86 GB per camera per day, or 34 GB across forty cameras over a month.

The unit trap, stated properly

Drive manufacturers use decimal capacity and say so. Seagate, in the SkyHawk datasheet:

"When referring to drive capacity, one gigabyte, or GB, equals one billion bytes and one terabyte, or TB, equals one trillion bytes. Your computer's operating system may use a different standard of measurement and report a lower capacity."

The usual shorthand is "you lose about 7%". That is right at the gigabyte level and wrong where surveillance actually operates, because the discrepancy compounds with each power of 1024:

Conversion	Apparent loss
GB → GiB	6.87%
TB → TiB	9.05%
PB → PiB	11.18%

On a forty-camera job that two-point difference decides whether the array fits. Do the arithmetic in decimal, then state what the operating system will display.

The worked example

A realistic mixed UK commercial estate:

• 24 × 2 MP / 1080p — corridors, doorways, general coverage
• 12 × 4 MP — car park, yard, wide areas
• 4 × 8 MP / 4K — main entrance, gate, site overview

Settings: H.265, 15 fps, continuous 24/7, variable bitrate with a cap, audio off.

Planning bitrates — and these are engineering assumptions, not manufacturer figures. I have deliberately chosen conservative values rather than the optimistic end, for reasons that become clear below:

Class	Planning bitrate
1080p H.265 @ 15 fps	2.0 Mbit/s
4 MP H.265 @ 15 fps	3.5 Mbit/s
4K H.265 @ 15 fps	6.0 Mbit/s

Step 1 — aggregate the bitrate

24 × 2.0 = 48.0
12 × 3.5 = 42.0
 4 × 6.0 = 24.0
         -------
Total    = 114.0 Mbit/s

Step 2 to 5 — turn it into storage

114.0 Mbit/s × 10.8 GB        = 1,231.2 GB per day
1,231.2 GB × 30 days          = 36,936 GB
                              = 36.94 TB (decimal)
                              = 33.59 TiB as the OS reports it

Across retention periods, with H.264 derived using the manufacturer's own measured 25% difference:

Retention	H.265 (114 Mbit/s)	H.264 (152 Mbit/s)
14 days	17.24 TB	22.98 TB
30 days	36.94 TB	49.25 TB
90 days	110.81 TB	147.74 TB

Note what that H.264 column depends on. Using the measured 25% saving gives 49.25 TB at thirty days. If you instead believed the "H.265 halves your storage" claim, you would write down 73.87 TB. One assumption, chosen carelessly, moves the answer by 24.6 TB — two thirds of the entire H.265 requirement.

Now the honest part: the same estate, sized the optimistic way

Bosch is unusual in publishing real bitrate tables in its public datasheets. Its figures for a 4K camera at 15 fps in H.265 are 4.10 Mbit/s, and for a 1080p camera well under one. Run the same forty cameras on those numbers:

Total    = 39.1 Mbit/s
39.1 × 10.8 × 30 = 12,668 GB = 12.67 TB

12.7 TB against 36.9 TB. Same forty cameras, same codec, same frame rate, same retention. A 2.9× spread.

Neither figure is dishonest. The difference is that every published Bosch bitrate is labelled an "optimised profile" — meaning their Intelligent Streaming and dynamic noise reduction are active, measured in their test scene. Those are a floor, not a forecast.

This is the real answer to the question. Anyone who gives you a single TB number for "forty cameras, thirty days" without stating the scene, the encoder profile and whether smart codecs are assumed on is guessing, and the guess has a 3× error bar.

What actually moves the number

H.265 saves about 25%

The cleanest evidence available is a single Bosch 4K camera whose datasheet prints H.264 and H.265 side by side, same sensor, same scene, same profile:

fps	H.264	H.265	Saving
25	7,820	5,860	25.1%
15	5,460	4,100	24.9%
8	3,520	2,640	25.0%
4	2,180	1,630	25.2%
2	1,350	1,010	25.2%
1	840	630	25.0%

Flat 25% across the whole range. Meanwhile the marketing figures in this sector run to "up to 80%" and "up to 90%" — but read those carefully and they bundle the codec with a smart codec and noise reduction. When the codec variable is isolated, it is a quarter. Size on 25% and treat anything better as upside.

Frame rate does not scale linearly

This one surprises people. From three separate Bosch tables:

Camera	fps change	Bitrate ratio
4K H.264	30 → 15 (halved)	68%
1080p H.265	30 → 12 (−60%)	73%
1080p H.264	30 → 15 (halved)	80%

Halving the frame rate buys roughly 20–32%, not 50%, because intra-coded frames dominate the stream and you are not halving those. A great deal of published calculator output quietly assumes linearity.

Smart codecs are real but cannot be designed around

Axis publishes six measured Zipstream scenes, and the honest thing about them is the range: 25% reduction in a well-lit scene with occasional motion, rising to 90% on a dark noisy scene and 99.7% at night with very infrequent motion.

Independent testing tempers that. IPVM, the trade research outlet, measured a comparable technology from another vendor at 15–30% in well-lit scenes and up to 50% in low light, explicitly short of the vendor's predictions.

A span from 25% to 99.7% is not a design input. Size the system without smart codecs and enjoy the saving in service.

Constant versus variable bitrate decides whether your arithmetic is a promise

Axis is refreshingly direct in its own white paper: constant bitrate "is not optimal for storage because it may contain padding data and waste storage space", and Axis products do not use it at all. Variable bitrate gives predictable quality and unpredictable size — and the excursion is large. Axis's own comparison shows a stream capped at 500 kbps against one reaching approximately 4,000 kbps during a short period of movement in the same scene. An eightfold spike.

So: if you are contractually guaranteeing thirty days of retention, a capped bitrate makes the arithmetic hold. You then have to size the network for the peak rather than the average.

Three things I am not going to give you a number for

Being straight about the limits of this is more useful than filling the gaps.

Night versus day. The mechanism is documented in both directions — greyscale video has a significantly lower bitrate than colour, but sensor noise under gain pushes it back up, which is precisely why noise reduction features exist. The indirect evidence that night bitrate is noise-dominated is that smart codecs can strip 90% or more off a dark scene; you can only remove that much if that much was noise. But no manufacturer publishes a day-to-night multiplier. The widely repeated "night costs two to three times day" is not something I can source. The effect is real; the number is site-specific.

Motion-triggered recording. The common claim is a 60–80% saving and I could not find a manufacturer figure for it anywhere. Worse, it is structurally unpredictable: triggers fire on rain, foliage, headlights and insects on the dome, and pre- and post-roll multiply short events — a five-second event with five seconds before and ten after stores twenty seconds. If you promise a retention period on a motion-triggered system, you are promising something you cannot compute in advance.

A single bitrate per resolution. There isn't one. Two Axis cameras at identical settings have been independently measured at 488 kbit/s and 1.32 Mbit/s — a 2.7× difference within one manufacturer's range.

RAID, and what "usable" means

Three deductions stack, in this order: parity, then the decimal-to-binary conversion, then the space the recording software reserves for itself.

That third one has a real published number. Hanwha's guidance for its own VMS reserves 10 to 30 GB per local drive and 50 to 100 GB per network share, capped at 10% of the drive, and states that a minimum of 10% should always be maintained for system stability.

Applying that to our requirement:

Requirement                36.94 TB
+ 10% headroom          →  41.05 TB usable needed

RAID 6 across 8 × 8 TB drives gives 64 TB raw and 48 TB usable, which meets it with around 14% spare.

RAID 6 is the right default for surveillance at this scale, for a reason specific to this application: surveillance writes are large and sequential, so RAID 6's write penalty hurts far less than it would in a transactional system — while modern drive sizes make rebuild windows long enough that a second failure during rebuild is a genuine risk, which RAID 5 cannot survive. RAID 5 is acceptable only on small arrays with small drives and short retention. RAID 10 buys write performance you do not need at half the capacity.

One check almost nobody does: drive workload rating. Our estate writes 449 TB per year logically, which with RAID 6 write amplification is about 75 TB per drive per year across eight drives — comfortably inside the 180 TB/year rating of a surveillance-grade drive. The same estate at ninety days on a four-drive array would breach it. This is what surveillance-rated drives are for; desktop drives are not rated for continuous write.

And the obvious point that still needs saying: RAID is not backup. It survives a drive failure. It does not survive deletion, ransomware, fire, or somebody removing the recorder.

Retention: there is no legal minimum, and the ICO tells you not to size it to your disk

This is the part that should come first in any real project, and usually comes last.

The ICO is unambiguous:

"The UK GDPR and the DPA 2018 do not prescribe any specific minimum or maximum retention periods which apply to surveillance systems or the personal data you may process."

"Rather, it is the purpose of your processing that should determine your retention period."

And then the sentence that reframes this entire article:

"You should also not determine your retention period simply by the storage capacity of any surveillance system, or just in case you think the data may be useful in the future."

"We keep thirty days because that is what the recorder holds" is a compliance failure, not a policy. The exercise runs the other way: justify the period, then buy the storage.

The Surveillance Camera Code of Practice, which relevant authorities have a statutory duty to have regard to, says the same in its own terms — no more images should be stored than strictly required, and it states plainly that "it is not, therefore, possible to be prescriptive about maximum or minimum periods."

So where does thirty days come from? Convention, reinforced by sector guidance. The clearest published UK government example is prison CCTV guidance, which advises that information is not retained beyond 30 calendar days — while setting far longer periods for specific liabilities: over three years for personal injury exposure, six years for use-of-force and deaths in custody. A useful illustration that the right answer is driven by purpose and legal risk, not by hardware.

"Thirty days is the UK legal requirement" is simply false. If a specification asserts it, ask which instrument it comes from.

Bandwidth, which is usually the thing that actually fails

Our estate needs 114 Mbit/s sustained on the recording network. But average is the wrong figure to engineer to, and i-PRO publishes the guidance explicitly: design the network with sufficient margin for a burst approximately 1.5 times the typical value.

Design peak = 114 × 1.5 = 171 Mbit/s

A single gigabit recorder link sits around 17% utilised at peak, which is fine — but specify two links or ten-gigabit for growth and for playback while recording. The bottleneck in practice is the recorder's disks and network interface, not the access switches.

Offsite or cloud recording is where this becomes a different project. Recording all forty cameras offsite needs 114 Mbit/s of sustained upload, twenty-four hours a day, plus overhead — realistically 150 Mbit/s symmetric. That is a leased line, not a standard connection. The workable patterns are to record locally and replicate selectively, to send only substreams offsite, or to send only event clips.

And substreams are the single most under-used setting in this industry. Published figures for a 720p H.265 substream are around 450 kbit/s. For a sixteen-tile wall:

Approach	Client bandwidth
16 main streams	45.6 Mbit/s
16 × 720p substreams	7.2 Mbit/s

A 6.3× reduction — and it is not only bandwidth. Milestone states the point directly in its own documentation: adaptive streaming "reduces the network load and improves the decoding capability and performance of the client computer."

The physical reality is that a sixteen-tile wall on a 1080p monitor gives each tile roughly 480 × 270 pixels. Sending 4K to a 480-pixel tile wastes about 97% of the pixels and forces the client to decode sixteen 4K streams in real time. The catch is that the cameras must have a second stream configured, and on a great many installed estates they simply do not.

What we would actually do

Size conservatively, then measure. Take a planning bitrate at the pessimistic end, buy to that, then measure the actual aggregate bitrate on the commissioned system across a full seven-day cycle including nights and a weekend. Confirm the retention against the measured number, not the desk calculation. Given a 2.9× spread on identical hardware, no desk calculation should ever be contractual.

Fix the retention period first, with a reason. Then the storage question has one answer instead of a range.

Turn off proprietary bitrate modes before you measure, or you are measuring something you cannot reproduce on other hardware.

Configure substreams on every camera at commissioning. It is free, it is the difference between a wall that works and one that stutters, and retrofitting it across an installed estate is tedious.

And note that every manufacturer in this article attaches a disclaimer to its own figures. Bosch: "actual bitrate may vary depending on the scene, picture settings, and encoder profile settings." Axis: the tool's estimates "will invariably differ from the bandwidth measurements of the actual system installation." Genetec: "these calculations estimate bandwidth using industry averages." The manufacturers themselves decline to guarantee the arithmetic. That is the strongest possible argument for measuring rather than trusting a calculator, including ours.

---

Every absolute bitrate quoted above is from a published Bosch datasheet, and each is an optimised-profile figure with smart codec and noise reduction active. The planning bitrates in the worked example are our own conservative assumptions and are labelled as such. Axis, Hanwha, i-PRO and Vivotek do not publish per-resolution bitrate tables — their numbers sit inside design tools behind click-through terms.

DevSpark builds DevSpark VMS, a video management platform with a built-in storage and bandwidth planner that works with the ONVIF and RTSP cameras already on the wall, so the measurement above can be taken on your own estate before anyone commits to hardware. If you are sizing a job and want a second opinion on the arithmetic, get in touch.