How to calculate CCTV storage and bandwidth correctly

CamVerion team · 7 November 2026 · 7 min read

Storage is one of the easiest things to get wrong on a CCTV job, and the mistake often stays hidden until a customer needs footage that has already been overwritten. A system sold with "30 days of recording" that holds 12 days is not just a technical miss. It is a broken promise, and it usually surfaces at the worst possible moment.

The calculation itself is simple. The hard part is choosing honest inputs. This guide covers both.

The basic formula

Everything starts with bitrate, which is how much data a camera produces each second. For continuous recording:

Storage in GB per day = bitrate in Mbps × 86,400 ÷ 8 ÷ 1,000

The 86,400 is the number of seconds in a day. Dividing by 8 turns megabits into megabytes, and dividing by 1,000 turns megabytes into gigabytes.

Since 86,400 ÷ 8 ÷ 1,000 is 10.8, there is a useful shortcut:

GB per day per camera ≈ Mbps × 10.8

So a camera averaging 4 Mbps produces about 43 GB a day.

Then the full formula becomes:

Total GB = Mbps × 10.8 × cameras × days

A worked example

Take a small warehouse with 8 cameras, each averaging 4 Mbps, recording continuously for 30 days.

Step Calculation Result
One camera, one day 4 × 10.8 43.2 GB
All cameras, one day 43.2 × 8 345.6 GB
All cameras, 30 days 345.6 × 30 10,368 GB, or about 10.4 TB

Rounding up, you may be tempted to specify a 12 TB drive. But first, consider what the drive really gives you.

Why a 12 TB drive doesn't hold 12 TB

Drive makers count in decimal units, where 1 TB is 1,000,000,000,000 bytes. Many recorders and operating systems display binary units, so that same "1 TB" shows as about 0.91. A 12 TB drive therefore shows roughly 10.9 in the recorder's display. Your available space is also affected by file system overhead and any space reserved for pictures or logs.

The practical result is to leave a margin. A common rule of thumb is to size for 10 to 20 percent above your calculation. The exact margin is your judgement, but zero is the wrong answer.

The real challenge: choosing the bitrate

Formula results are only as good as your bitrate figure. Spec sheets and quick estimates can be far from what a camera does on site, because bitrate depends on several things.

Resolution

More pixels generally mean more data. Moving from 2MP to 4MP or 8MP increases bitrate, though not always in direct proportion.

Frame rate

Security recording does not always need 25 or 30 frames per second. Many general surveillance views work well at 10 to 15. Lowering the frame rate reduces storage, but for fast-moving subjects such as vehicles, you may lose useful frames. Choose by purpose.

Compression

H.265 can use noticeably less bandwidth than H.264 at similar quality, though the saving varies by scene and camera. Manufacturers' "smart" codecs can reduce it further on quiet scenes. Check that the recorder, playback software and any video management system all support the codec you choose.

Scene activity

This is the factor most often overlooked. A static storeroom may produce a fraction of the data of a busy entrance, a road or a scene with moving trees. Cameras with the same settings could differ by several times in real use.

Night mode

In low light, cameras often produce more image noise, and compression treats that noise as detail. Bitrate can rise sharply at night. A system sized from daytime tests may fall short.

CBR vs VBR

With constant bitrate (CBR), the camera aims for a fixed rate, so storage planning is simple but picture quality may fall during busy moments. With variable bitrate (VBR), the camera uses what the scene needs, up to a limit. This gives efficient recording, but your estimate must be based on the likely average. For a cautious plan, use a figure close to the maximum for busy cameras.

Getting a reliable bitrate figure

In order of trustworthiness:

  1. Measure on site or in a similar scene. Record for a full day and night, and then see how much drive space was used. Nothing beats this.
  2. Use the manufacturer's calculator. It reflects their model and codec, though it still needs an assumption about scene activity.
  3. Use your own records. Note actual storage use from past jobs with similar cameras. Over time, this becomes your best resource.
  4. Use a rule of thumb. This is acceptable for a rough first estimate, provided you say so.

Continuous, scheduled or motion recording

Recording only when something happens may reduce storage significantly, but it brings trade-offs.

  • Continuous: simple and complete, but uses the most space.
  • Scheduled: for example, recording continuously out of hours and on motion during the day.
  • Motion or event: efficient for quiet scenes. But poorly set detection might miss the start of an event, and moving shadows could cause a lot of false recording.
  • Dual stream: some systems record a lower-quality stream continuously and a high-quality stream on events. It offers a useful balance where supported.

If you size a system for motion recording, estimate how many hours of activity each camera sees. A cashier area might have activity all day. Be cautious, because customers tend to add cameras and change usage.

Check the recorder's limits

Sufficient disk capacity is not enough. An NVR also has limits that can stop a design from working.

  • Incoming bandwidth. Each NVR has a maximum total recording bandwidth. Adding up all the cameras must leave room under that limit. In the example above, 8 × 4 Mbps is 32 Mbps, which most 8-channel NVRs handle. But 16 cameras at 8 Mbps would need 128 Mbps, so check the data sheet.
  • Outgoing bandwidth. Playback and remote viewing also use capacity, and several users can reach this limit at once.
  • Number and size of drive bays. Check maximum size per bay, and which models the manufacturer has approved.
  • Decoding capacity. This limits how many cameras can be displayed at a given resolution on the monitor at the same time.

Planning network capacity

Bitrate also determines what your network must carry.

  • Add up all the cameras on each switch and uplink. A 100 Mbps uplink could be tight for 16 busy cameras, so consider gigabit uplinks. It is common to size so that links are not close to their limit.
  • Keep camera traffic separate from the customer's business network where you can.
  • Remote viewing uses the site's upload speed. If a site has 10 Mbps upload, a user cannot watch several high-resolution streams at once. Most systems offer a lower-bitrate "sub stream" for this purpose.

To size upload, estimate the number of simultaneous remote streams and the bitrate of the sub stream, then add a little headroom.

Drive choice and redundancy

Use drives made for surveillance. They are designed for near-continuous writing, whereas desktop drives are not. Check that the manufacturer of your recorder supports the model.

On systems where losing footage would be serious, consider redundancy.

  • RAID 1 mirrors two drives. You get half the raw capacity.
  • RAID 5 survives one failed drive, and you lose one drive's worth of capacity.
  • RAID 6 survives two failures, and you lose two drives' worth.
  • Hot spare drives can take over quickly if one fails.

Keep in mind that RAID is not a backup. It protects against a failed drive, but not against theft of the recorder or deletion. For critical footage, keep a copy off site or export important incidents right away.

Remember to include the redundancy capacity in your quote, since customers may be surprised by how many drives are needed for the usable size you promised.

Common mistakes

  • Using only the daytime bitrate. Night scenes can increase it.
  • Assuming every camera is the same. Calculate entrances and quiet stores separately.
  • Selling days without a condition. Say "approximately 30 days at these settings", since retention depends on activity.
  • Leaving no margin. Drives also lose capacity to formatting.
  • Not checking after installation. See how much space was used after one week, then project forward.
  • Adding cameras later without recalculating. The same drive divided across more cameras gives fewer days.
  • Keeping more than you need. Longer retention costs money and may create privacy obligations.

A quick sizing sheet

You can set up this table in a spreadsheet for any job.

Camera group Cameras Mbps Hours per day GB per day
Entrances 2 6 24 2 × 6 × 10.8 = 129.6
Warehouse 4 4 24 4 × 4 × 10.8 = 172.8
Offices, on motion 2 3 8 2 × 3 × 3.6 = 21.6
Total 8 324 GB

Here, hourly storage is Mbps × 0.45 GB, so 8 hours gives Mbps × 3.6. For 30 days, the total is 324 × 30 = 9,720 GB. With a 20 percent margin, you need about 11.7 TB usable.

What to put in your quote

State the assumptions, so that both sides know what was promised:

"Storage sized for approximately 30 days at the configured settings with typical site activity. Actual retention varies with scene activity and settings."

Then check real retention at your first service visit. Include it in your handover process, and tell the customer when footage is overwritten, so they know to export a clip promptly after an incident.

Getting this right builds trust. A customer who finds footage when they need it becomes your best source of referrals.

Run your next CCTV job from one place

Sign up with your company details. We verify them, approve your account once your setup fee is received, then you can add your team.

Request a demo

Leave your email and we will get in touch to set up a short demo.