CCTV Storage and Network Planning Calculator
Adding cameras to a running facility? Enter each group of cameras with the bitrate your recorder actually shows, how long footage must be kept and the reserve you hold free — and see the storage the expansion needs and the load it puts on the recorder and network.
- Expansion
- Renovation
- Operating cost
What this tool estimates
The recording storage your camera groups need for the retention you set, in decimal terabytes; the usable capacity to provision once a free-space reserve is kept; and the recording bitrate the groups put on the recorder and network — with the share the expansion adds.
What it cannot decide
- What bitrate a camera will record: that depends on the scene, light, codec and settings — take it from your recorder or camera configuration.
- Which RAID level, disk count or recorder to buy, or how much of the raw disk a RAID layout leaves usable unless you enter it.
- The network design: switch ports, PoE power budgets, uplinks, live-view and remote-viewing streams.
- How long footage must be kept — retention is a policy, insurer or authority requirement you set.
Result
Decimal TB, as disks are sold (10¹² bytes). Operating systems show binary TiB, which reads about 9% lower for the same disk. Live view, playback and remote viewing add network traffic but no storage.
| Group | Status | Cameras | Mbps each | GB per camera per day | TB kept | Share |
|---|
| Step | Value |
|---|
| Bitrate |
|---|
Method version 6 October 2026. A screening estimate, not a design: see the limits below.
How this calculator works — and where it stops
What it calculates
The storage a CCTV system needs to keep footage for the retention you set, in decimal terabytes as disks are sold; the usable capacity to provision once a free-space reserve is held back; the raw disk that implies if you enter your RAID layout's usable fraction; and the recording bitrate all the camera groups put on the recorder and network. Each group is marked new (added by this expansion) or existing, so the expansion's own share is shown.
Inputs
- Camera groups — cameras that record alike — each with the number of cameras; the recorded bitrate per camera in Mbps or kbps, as the recorder or camera configuration shows it; the recording hours per day; and the share of those hours actually recorded (1 for continuous recording, less only for event recording and only from the recorder's logs).
- Whether each group is new (added by this expansion) or existing.
- Retention in days.
- Free-space reserve: the share of usable capacity kept free, from 0 up to (not including) 100%.
- Optional: the RAID usable fraction (usable ÷ raw), the usable storage already installed (TB) and the recorder's incoming-bandwidth limit (Mbps) from its datasheet.
Method
- Bytes per camera per day = Mbps × 10⁶ ÷ 8 × recording hours × 3,600 × share recorded.
- Video kept (TB) = Σ cameras × bytes per camera per day × retention days ÷ 10¹² — decimal terabytes.
- Usable capacity to provision = video TB ÷ (1 − free-space reserve).
- Raw disk = usable ÷ RAID usable fraction, only when you enter one; otherwise the result is stated as before RAID.
- Recording bitrate = Σ cameras × Mbps each — every group recording at once. The storage reserve is not part of it, and neither the schedule nor the share recorded lowers it, because at the busiest moment every camera can be recording.
- The groups marked new give the expansion's own bitrate and usable storage. The optional checks subtract the need from the storage installed and the bitrate from the recorder's input limit; a shortfall is shown as a shortfall.
- Sensitivity: the usable TB is recomputed with the bitrate −25% to +50% and the retention halved and doubled.
Assumptions
- The bitrate entered is the average recorded bitrate of the stream that is stored. For a variable-bitrate stream the configured maximum is a ceiling, and night-time noise, rain and busy scenes push the real figure towards it.
- Each group's share recorded holds across the retention period; event recording is only as small as the scene is quiet.
- Decimal units throughout: 1 Mbps = 10⁶ bit/s and 1 TB = 10¹² bytes. Operating systems show binary TiB (2⁴⁰ bytes), so the same disk reads about 9% lower there.
- The free-space reserve is your choice; no value is recommended.
Limitations
- Does not estimate bitrate from resolution, frame rate or codec. That needs the camera's own figures or a manufacturer's design tool — and is still an estimate.
- Does not choose the RAID level, disk sizes, hot spares or recorder, and does not model file-system overhead.
- Does not design the network: switch ports and backplane, PoE power budgets, uplinks, and the extra streams for live view, playback and remote viewing.
- Does not set the retention — that comes from your policy, your insurer or the authority that requires it.
Worked example
Produced by running this calculator with the inputs below.
Inputs
- One group of 16 new cameras, added by the expansion
- Recorded bitrate 4 Mbps per camera
- Recording 24 hours a day; share recorded 1 (continuous)
- Retention 30 days
- Free-space reserve 20%; no RAID fraction entered
Working
- Per camera per day = 4 × 10⁶ ÷ 8 × 24 × 3,600 × 1 = 43.2 × 10⁹ bytes (43.2 GB).
- Video kept = 16 × 43.2 GB × 30 days = 20.736 × 10¹² bytes = 20.736 TB.
- Usable to provision = 20.736 ÷ (1 − 0.20) = 25.92 TB, before RAID.
- Recording bitrate = 16 × 4 = 64 Mbps; the 20% reserve does not enter it.
Result. 20.736 TB of video, 25.92 TB of usable storage to provision before RAID, and 64 Mbps of recording on the recorder and network — all of it added by the expansion.
Sensitivity — what moves the answer
- Storage scales directly with bitrate and retention: if the cameras really record 25% more than entered (5 Mbps), the usable need is 32.4 TB; keeping 60 days instead of 30 doubles it to 51.84 TB.
- RAID is not free: the same 25.92 TB built as RAID 6 on eight equal disks (usable fraction 6 ÷ 8 = 0.75) needs 34.56 TB of raw disk.
- Event recording at a share of 0.5 halves the storage but leaves the 64 Mbps recording bitrate unchanged — the recorder and network must still take every camera at once.
How engineers use the result
To scope a CCTV expansion before choosing hardware: how much storage the new cameras add for the required retention, whether the installed recorder's disks and input bandwidth can take them, and how sensitive both are to the bitrate the cameras actually record.
When a professional design must replace it
Before ordering recorders or disks: an engineer should confirm each group's recorded bitrate on the recorder by day and by night, the retention requirement and where it comes from, the RAID layout and hot spares, the recorder's input and disk limits, and the network's switch, PoE and uplink capacity including live-view streams.
Sources
- Axis Communications — AXIS Site Designer user manual (updated January 2026) — bandwidth and storage depend on scene, light, schedule and compression settings and are estimates only; live view adds bandwidth but not storage; RAID reduces available capacity; disks are sold in decimal TB while operating systems show binary TiB
- Decimal units: 1 Mbps = 10⁶ bit/s; 1 TB = 10¹² bytes — definitions; no standard, vendor default or bitrate table is applied by this tool
Questions people ask before using it
What information do I need before using the CCTV storage calculator?
For each group of cameras that record alike: how many there are and the recorded bitrate per camera as your recorder or camera configuration shows it (for a variable bitrate, the configured maximum is a ceiling; the recorder's own bitrate display over a day and a night is closer); the recording schedule in hours per day; and, only if the group records on events, the share of those hours it actually records, taken from the recorder's logs. Then the retention period, the free-space reserve you keep, and — if you want those checks — the RAID usable fraction, the usable storage already installed and the recorder's incoming-bandwidth limit from its datasheet.
Which site conditions could change the CCTV storage result?
Low light and night-time noise, rain, moving foliage and busy scenes all raise the bitrate of a variable-bitrate stream; so do changes to codec, resolution, frame rate or compression settings. Event-recorded groups record more than expected where something always moves. Axis's Site Designer manual makes the same point — scene type, light, schedule and compression settings drive its bandwidth and storage figures, which it calls estimates only.
What should I send an engineer for a CCTV expansion review?
The camera schedule — existing and new, by location and purpose — the recorder and storage details (model, disks, RAID level and the retention it achieves today), the bitrate settings or the recorder's bitrate display for each group, the network layout with switches, PoE budgets and uplinks, the retention requirement and who set it, and this calculator's export.
Optional: ask an engineer to look at it
The result above is yours with no form. If you want an engineer to check it against your drawings, schedules or bills, send a request. Nothing is sent until you press the button.
Request saved
It reached our team with exactly what the preview showed. An engineer will use the number you gave if they need your drawings or data.
Prefer to talk? WhatsApp or the contact form.
Got your number — what next?
A calculator gives you a first figure. These take it further.
The work itself
Read before you specify
The terms behind it
Delivered work with this scope
- Operational Excellence for a Logistics Major— Nahar Logistics
- Fire Fighting & ELV for Benson Hotel— Benson Hotel
One of 56 free MEPF and solar calculators on this site. Every input term is defined in the engineering glossary; the specification libraries, clearance guides and checklists for design teams are in the architects' section.