CCTV Storage Calculator
Translate measured average video and audio bitrates into daily recording volume, raw retention storage, a reserve-adjusted target, and the retention your proposed drive array can support. The result keeps stream demand and usable disk capacity separate so RAID or other overhead is not counted twice.
Retention and array result
Capacity trace
8 cameras × 4.064 Mb/s = 32.512 Mb/s active 32.512 Mb/s × 24.00 h/day = 351.130 GB/day 351.130 GB/day × 30 days × 1.200 reserve factor = 12.641 TB
Three storage layers prevent a false sense of capacity
Stream workload
The camera count and per-camera video-plus-audio bitrate determine the active aggregate stream. Scheduled hours and the expected active percentage convert that stream into a daily recording volume. This is the footage arriving for storage, before retention or array design.
Retention target
Daily volume multiplied by retention days produces raw storage. The reserve percentage is then added as free-space and uncertainty margin. Reserve is not RAID overhead; it remains available inside the usable recording pool for spikes, metadata, exports, and operational margin.
Usable array
Nameplate drive capacity multiplied by drive count gives raw hardware capacity. The usable-fraction input reduces it for the proposed RAID layout, formatting, file system, hot spare policy, or other known overhead. Compare that usable figure with the reserve-adjusted target.
The calculator uses decimal drive units: 1 TB equals 1,000,000,000,000 bytes. It also converts the reserve-adjusted target to tebibytes, where 1 TiB equals 1,099,511,627,776 bytes. Operating systems and vendors may label capacity differently, so both numbers help reconcile an apparent discrepancy without changing the underlying byte requirement.
Worked example: eight continuously recording cameras
The default plan has eight cameras, each averaging 4 Mb/s of video and 64 Kb/s of audio. Audio converts to 0.064 Mb/s, making 4.064 Mb/s per camera. Eight cameras produce an aggregate active bitrate of 32.512 Mb/s. Because the schedule is 24 hours per day and expected activity is 100 percent, the effective recording duration is 24 hours daily.
Converting bits to bytes and seconds to hours produces approximately 351.130 decimal GB each day. Over 30 days, raw recordings require about 10.534 TB. A 20 percent reserve increases the usable storage target to 12.641 TB, equivalent to roughly 11.497 TiB.
The proposed array contains four 8 TB drives and assumes 75 percent of their nameplate total is usable after the selected storage layout and overhead. That yields 24 TB usable. It exceeds the 12.641 TB target by about 11.359 TB. Keeping the same workload and 20 percent reserve, it could support approximately 56.96 days before reaching the planned allocation boundary.
This fit does not guarantee recording integrity. Sustained write performance, drive workload rating, rebuild behavior, simultaneous playback and export, database overhead, health monitoring, redundancy during failure, power protection, and backup or evidence-export policies still matter. Storage capacity is only one dimension of a recorder design.
Use bitrate—not resolution—as the primary input
Two cameras at the same resolution can generate very different data volumes. A busy street, foliage, rain, sensor noise, low-light gain, detailed textures, frequent lighting changes, and long groups of pictures can alter compression demand. Codec, frame rate, quality target, rate-control mode, and analytic overlays also matter. Entering “4K” does not uniquely determine storage.
Current Axis documentation describes average bitrate as a control that adjusts over a longer period to meet a storage objective and notes that motion-heavy scenes may temporarily require more bitrate. That is why a measured average over representative days is better than a marketing estimate. Include daytime, night, weather, weekday, weekend, and special-event conditions when they materially change the scene.
Continuous recording
Set scheduled hours to the daily recording window and activity to 100 percent. If every camera does not share the same schedule, calculate camera groups separately and add their target storage. Grouping prevents a lobby camera’s business-hours schedule from hiding a parking camera’s around-the-clock requirement.
Motion or event recording
Use the active percentage only when it is supported by representative logs or a careful pilot. Ten percent activity does not mean ten percent of the continuous bitrate if pre-event buffers, post-event time, dual streams, analytics, audio, or event bursts behave differently. Test conservative cases.
What to include in the capacity reserve
| Uncertainty | Why it changes capacity | How to address it |
|---|---|---|
| Bitrate variation | Variable and average bitrate streams can rise during complex or active scenes. | Use measured distributions, test busy periods, and maintain free-space margin. |
| Recorder metadata | Indexes, databases, thumbnails, analytics, logs, and file-system overhead consume storage outside the simple media stream. | Review VMS documentation and include known overhead explicitly or in reserve. |
| Exports and locks | Incident footage may be protected from overwrite or exported locally, temporarily reducing normal recording space. | Define a separate evidence workflow and capacity allocation. |
| Growth | Future cameras, higher frame rates, audio, or changed quality settings add workload. | Model the planned end-state camera count as a separate scenario. |
| Drive and array behavior | Redundancy, spares, formatting, rebuilds, and vendor reservations reduce nameplate capacity or availability. | Use the storage platform’s actual usable capacity and failure policy. |
Do not hide every unknown inside one enormous percentage. Keep major known costs—such as RAID usable fraction—separate, then use reserve for residual uncertainty and operating headroom. This avoids double-counting and makes later updates easier when the storage platform is selected.
A deployment-ready validation workflow
- Group similar cameras. Separate cameras by model, codec, scene, frame rate, schedule, and recording method instead of relying on one universal average.
- Measure representative bitrate. Collect enough history to capture day, night, weather, motion, and event conditions. Use planned maximum-average settings where the camera supports them.
- Confirm the policy period. Establish how retention is counted, when overwrite occurs, and how incident holds affect normal rotation.
- Calculate each group. Run this calculator for each distinct workload and add reserve-adjusted targets.
- Obtain real usable capacity. Use the recorder or array vendor’s configuration result after redundancy, spares, formatting, and reservations.
- Test performance and failure states. Verify sustained ingestion, playback, export, rebuild, failover, monitoring, and recovery with realistic traffic.
- Recheck after commissioning. Compare actual daily growth and retention against the model, then adjust bitrate, schedule, or capacity before margin disappears.
Neither includes VMS databases or array overhead.
Frequently asked questions
How much storage does one 4 Mb/s camera use per day?
At 4 Mb/s with no audio and continuous 24-hour recording, the ideal decimal volume is about 43.2 GB per day. Actual storage can differ because the entered rate may not represent the real average, and the recorder adds metadata, indexing, file-system, reserve, and platform overhead.
Should I enter maximum bitrate or average bitrate?
Use a defensible average for retention capacity, then test peaks and performance separately. A maximum instant bitrate can overstate long-term storage if sustained average control is effective, while a low optimistic average can understate busy scenes. Representative measurements and manufacturer rate-control behavior are best.
What does array usable fraction mean?
It is the percentage of total drive nameplate capacity expected to remain usable for the recording pool after the planned redundancy, spares, formatting, and other known platform overhead. Obtain this figure from the actual array configuration rather than assuming every RAID level has one universal percentage.
Why are TB and TiB different?
Decimal TB uses powers of 1,000, while binary TiB uses powers of 1,024. One decimal TB is smaller than one TiB. Drive vendors commonly advertise decimal TB, while some operating systems present binary capacity. The calculator shows both for the target so labels can be reconciled.
Can I estimate motion recording with the activity percentage?
Yes, as a scenario, but the percentage should come from representative evidence. Pre-event and post-event recording, audio, metadata, changing frame rates, event bursts, and parallel low-resolution streams can make actual volume differ from a simple duty cycle.
Does RAID replace backup?
No. Redundancy can improve availability after some drive failures, but it does not by itself protect against deletion, corruption, recorder failure, theft, fire, malware, misconfiguration, or site loss. Define evidence export and backup requirements according to organizational risk and policy.
References
- Axis Communications, AXIS Camera Station 5 User Manual: Recording Method and Average Bitrate
- Axis Communications Developer Documentation, Rate Control
- Axis Communications, AXIS OS Web Interface Help, LTS 2026: Bitrate Control and Retention
Planning estimate only. Verify the actual camera streams, VMS overhead, drive workload, usable storage, failure behavior, cybersecurity controls, privacy obligations, and retention policy before procurement or deployment.