---
title: How to Size IP Camera Storage for 30-Day Video Retention
slug: ip-camera-storage-sizing-30-day-retention
canonical_url: "https://ztronyx.com/kb/ip-camera-storage-sizing-30-day-retention"
published_at: "2026-09-08T00:00:00+00:00"
updated_at: "2026-09-08T00:00:00+00:00"
description: Calculate 30-day IP camera storage from measured bitrate, then account for overhead, motion, outages, RAID policy, growth, and acceptance testing.
tags:
  - camera storage calculator
  - 30 day video retention
  - NVR sizing
  - surveillance bitrate
  - H.265 recording
  - recording resilience
---


A recorder advertised with 24 TB does not automatically deliver 30 days of usable evidence. Resolution is only one variable. Scene motion, low-light noise, codec, frame rate, group-of-pictures settings, multiple streams, audio, metadata, recording schedules, filesystem overhead, disk protection, and reserved space can change the result. A spreadsheet that starts with “4K equals X GB per day” creates false precision.

**Answer first:** size storage from representative measured average bitrate, not resolution alone. Convert that bitrate to daily capacity, apply the real recording duty cycle, then add explicit allowances for implementation overhead, operational reserve, growth, and disk-failure policy. Separately test peak aggregate bitrate against network and recorder ingest limits. Finally, prove retention in the commissioned system by reading the oldest continuously available video after a representative soak period.

This guide uses the [Hanwha XRN-1620B2-24TB 16-channel NVR](https://ztronyx.com/products/XRN-1620B2-24TB) and [Hanwha XNV-9083R 8MP outdoor dome](https://ztronyx.com/products/XNV-9083R) as real examples. The live Ztronyx feed lists both as in stock. It describes the recorder as 24 TB **raw** with H.265, H.264, and MJPEG support, and the camera as an 8 MP outdoor IR vandal dome. Calculations below are design assumptions, not claimed factory bitrates or guaranteed retention.

## The storage formula

For continuous recording in decimal units:

`TB per day = average Mb/s × 86,400 ÷ 8 ÷ 1,000,000`

Simplified:

`TB per day = average Mb/s × 0.0108`

For a group of cameras:

`raw video TB = average Mb/s per camera × cameras × 0.0108 × days × duty cycle`

Duty cycle is 1.0 for continuous recording. A measured 40% event-recording duty cycle is 0.40. Never apply a motion percentage merely because a proposal template expects one.

Then calculate planned capacity:

`planned usable TB = raw video TB × overhead factor × reserve factor × growth factor`

Keep each factor visible. For example, 1.05 for implementation overhead, 1.20 for operational reserve, and 1.10 for planned growth are separate assumptions whose owners can approve or change. Do not quietly roll every uncertainty into an unexplained percentage.

## Why measured bitrate matters

Video bitrate changes with information the encoder must preserve. A quiet hallway in daylight is easier to compress than rain at night, moving leaves, vehicle headlights, crowds, digital noise, or a repositioning PTZ. Frame rate, GOP length, compression, WDR, and multiple client streams also affect demand.

Axis's primary-source bitrate paper explains tradeoffs among variable, maximum, and average bitrate controls. Variable bitrate protects quality but makes storage less predictable. An aggressive maximum cap improves predictability but can remove forensic detail in complex scenes. Although that paper describes Axis controls, the general lesson is vendor-neutral: a bitrate limit is a quality decision, not merely a storage knob.

Measure the exact camera and firmware with the intended scene, lens view, codec, resolution, frame rate, quality, WDR, IR, analytics, audio, and VMS profile. If the VMS requests a different stream than the browser preview, the preview measurement is irrelevant.

## Step 1: Define the evidentiary requirement

“Thirty days” needs a precise acceptance definition. Decide:

- whether retention means 30 × 24 hours or 30 calendar dates;
- whether each camera records continuously, on event, or by schedule;
- required pre-event and post-event video;
- resolution, frame rate, quality, audio, and metadata;
- what happens when storage fills;
- which cameras need longer retention;
- whether legal hold or exports consume recorder space;
- the allowed recording gap during maintenance or failure.

Translate policy into per-camera rows. A parking entrance used for vehicle context may need a different profile from an interior utility room. Do not force every camera into one configuration simply to make arithmetic easier.

Identify the owner of each requirement. Security should define evidentiary quality and operational risk; legal or privacy teams should define retention constraints; IT should validate network, identity, backup, and monitoring; the integrator should document device capabilities and measured performance.

## Step 2: Capture representative samples

For each camera class, collect bitrate during:

1. normal business activity;
2. quiet periods;
3. day-to-night transition;
4. darkness with IR active;
5. rain, snow, wind, foliage, or other high-complexity conditions;
6. a staged incident with expected motion;
7. simultaneous live viewing and playback if they create extra streams.

Use VMS statistics, camera telemetry, or managed-switch counters. Record average, 95th percentile, and observed peak. Average drives expected storage; upper-percentile and peak values help set reserve and prove ingest and network capacity.

For event recording, measure active time over a representative period. A loading dock can be quiet Sunday and nearly continuous Monday. Validate motion masks, object filters, sensitivity, pre-event buffer, and post-event timer before relying on duty-cycle savings. Include weather and seasonal effects where possible.

## Step 3: Calculate base retention

Consider eight cameras measured at an average of 4 Mb/s with continuous recording:

| Input | Value |
|---|---:|
| Average per camera | 4 Mb/s |
| Camera count | 8 |
| Daily video | 0.3456 TB |
| 30-day raw video | 10.368 TB |

Daily capacity is `4 × 8 × 0.0108`. Thirty days is `0.3456 × 30`.

If the project applies a documented 5% implementation allowance and 20% operational reserve:

`10.368 × 1.05 × 1.20 = 13.064 TB planned usable capacity`

That result does not mean a “14 TB” appliance is automatically sufficient. Confirm actual usable capacity after formatting and the selected protection configuration. Determine whether exported clips, databases, thumbnails, metadata, and system reserves are included in displayed free space.

Now consider twelve cameras averaging 6 Mb/s:

`6 × 12 × 0.0108 × 30 = 23.328 TB`

This already approaches the XRN-1620B2-24TB listing's 24 TB raw capacity before overhead or reserve. It is not a defensible 30-day design. Reduce count or measured average without compromising evidence, shorten retention through approved policy, or select more storage.

For one camera at 6 Mb/s, 30-day raw video is 1.944 TB. This is why search results offering one storage number for every 4K camera are misleading: the input bitrate, recording schedule, and reserve determine the outcome.

## Step 4: Separate raw, usable, and protected capacity

Procurement sheets often present raw disk capacity. The recorder can show less because of decimal/binary display, formatting, system partitions, metadata, reserved space, or disk-protection mode. Mirroring, parity, hot spares, and other resilience choices can further change usable capacity.

Do not infer a RAID level or usable percentage for XRN-1620B2-24TB from its name. Current Hanwha documentation and the commissioned interface must determine supported modes and available capacity for installed drives and firmware.

Record four numbers:

1. installed raw capacity;
2. displayed usable recording capacity;
3. required planned capacity;
4. free-space floor that triggers action.

If disk-failure tolerance is required, state allowed failures, rebuild behavior, performance impact, hot-spare policy, and replacement objective. RAID may improve availability, but it is not backup and does not protect against deletion, theft, corruption, compromise, or a site-wide event.

Reserve should cover uncertainty, not conceal it. Keep measurement error, scene variation, growth, and degraded-disk operation as separate risk statements. If stakeholders reject a reserve to meet a budget, document the resulting retention risk instead of manipulating bitrate assumptions.

## Step 5: Verify ingest and network capacity

Storage can fit while recording fails. Recorder and network must handle peak recording, playback, export, edge-storage reconciliation, analytics, and clients.

Build two totals:

- **expected load:** sum of representative average bitrates;
- **stress load:** sum of configured maximums or high-percentile measurements, plus secondary streams and overhead.

Compare both with current manufacturer-documented recording throughput and channel limits. Model capabilities may differ by firmware, streams, AI mode, or connected camera. Verify the exact configuration, not a reseller title.

Check every hop. A 1 Gb switch port does not guarantee end-to-end performance if a recorder interface, firewall, wireless bridge, oversubscribed uplink, or storage write path is the bottleneck. Monitor packet loss, interface errors, retransmissions where applicable, and VMS dropped-frame or recording-health alarms during stress.

Run simultaneous playback and export because investigations rarely happen only when live traffic is quiet. Measure whether search responsiveness or recording health degrades. Confirm that management traffic and backup jobs do not contend with camera ingest on undersized links.

## Step 6: Design for outages and clock integrity

Central recording has at least four failures: camera power, network path, recorder service, and disk. Decide which must preserve video and for how long.

Hanwha documents edge-storage capability for the XNV-9083R family. Exact slot count, media type, capacity, and recorder behavior must be verified against the current regional data sheet and installed firmware; capability alone is not proof of automatic recorder reconciliation. Edge recovery depends on supported media, endurance, filesystem, firmware, recorder integration, event rules, and synchronized time.

If recovery is required, test it:

1. synchronize camera and recorder to approved NTP;
2. configure edge recording as designed;
3. disconnect the network for a controlled interval;
4. generate visible test activity;
5. restore connectivity;
6. verify whether footage reconciles automatically, is manually accessible, or is missing centrally;
7. measure recovery traffic and live-recording impact;
8. confirm overwrite behavior if the outage exceeds edge capacity.

Do not advertise “zero recording loss” unless this exact test passes and remaining power, storage, and hardware failure cases are covered. Repeat after material firmware or VMS upgrades.

## Step 7: Secure operations and evidence

Retention is an availability and integrity requirement. Put cameras and recorders in restricted segments; deny direct internet exposure by default; use unique managed credentials; limit administration to approved jump hosts; patch under change control; and monitor authentication, configuration, storage, and stream-health events.

Use least-privileged service accounts for ONVIF or APIs. Confirm that camera replacement, certificate renewal, and updates do not create a new stream profile with different bitrate. Read the [Ztronyx ONVIF guide](https://ztronyx.com/kb/onvif-streaming-standard-architecture-protocols) before assuming discovery guarantees edge recovery, analytics, metadata, or storage interoperability.

Back up recorder configuration and document restoration. Protect exported evidence with access controls and chain-of-custody practices required by site policy. Store critical exports separately from the rolling recorder volume. Legal and privacy requirements determine who may view, retain, export, and delete recordings.

## Troubleshooting retention shortfalls

### Oldest video is younger than planned

Compare actual average bitrate, duty cycle, usable capacity, camera count, added streams, and reserve assumptions. Look for profile changes after updates, new clients, continuous recording where event recording was intended, or newly enabled audio and metadata.

### Retention drops only during storms or at night

High motion, precipitation, insects, foliage, headlights, and low-light noise increase bitrate or motion duty cycle. Sample the affected period and tune lighting, view, noise reduction, event masks, or bitrate controls without sacrificing required evidence.

### Capacity appears correct but gaps exist

Inspect recorder health, disk events, network loss, time jumps, stream authentication, and per-camera recording schedules. Capacity arithmetic cannot detect a failing disk or rejected stream.

### Video quality fails during busy scenes

An overly low maximum bitrate can preserve retention by discarding detail. Stage representative motion and inspect exported video at normal viewing and forensic zoom. Adjust the design, not just the cap.

## Acceptance checklist

- [ ] Retention and evidentiary quality are written per camera class.
- [ ] Bitrate samples cover busy, quiet, day, night, and adverse conditions.
- [ ] Average, upper-percentile, peak, and event duty cycle evidence is retained.
- [ ] Formula units and camera counts are independently reviewed.
- [ ] Raw, usable, required, protected, reserved, and growth capacities are separate.
- [ ] Recorder channel and throughput limits match current documentation.
- [ ] Peak ingest, live viewing, playback, export, and recovery traffic pass together.
- [ ] Disk failure and replacement behavior meet the approved objective.
- [ ] Edge recording and reconciliation pass an actual outage test if required.
- [ ] Time synchronization, credentials, certificates, updates, and alerts are verified.
- [ ] Oldest-video checks and incident exports pass for every camera.
- [ ] Configuration backup, as-built schedule, and recovery runbook are delivered.

## Buyer and operator guidance

Buy usable retention, not a raw terabyte label. A proposal should contain camera-by-camera assumptions, measurement evidence, formulas, reserve, protection mode, displayed usable capacity, throughput proof, and acceptance method. For the XRN-1620B2-24TB example, “24 TB raw” is the starting input, never the conclusion.

Operators should review actual oldest footage and average bitrate weekly during the first month and after material scene, firmware, lighting, or VMS changes. Trend free space, disk health, recording gaps, and bitrate outliers. Capacity planning becomes trustworthy only when forecast and observed retention are compared.

## Sources

- [Hanwha XRN-1620B2 product page and downloads](https://hanwhavisionamerica.com/product/xrn-1620b2/)
- [Hanwha XNV-9083R manufacturer data sheet](https://www.hanwhavision.com/en/products/camera/network/dome/xnv-9083r/)
- [Axis: Bitrate Control for IP Video](https://whitepapers.axis.com/en-us/bitrate-control-for-ip-video)
- [NIST: Video Surveillance Equipment Selection and Application Guide](https://www.nist.gov/publications/video-surveillance-equipment-selection-and-application-guide)
- [CISA: Securing Network Infrastructure Devices](https://www.cisa.gov/tips/st18-001)