CCTV Storage Retention — Frequently asked

Take the camera's recording bitrate in Mbps, multiply by 86,400 seconds, and divide by 8 to get megabytes per day. At a continuous 24/7 recording schedule that works out to roughly 21.6 GB per camera per day at 2 Mbps, 43.2 GB at 4 Mbps, 64.8 GB at 6 Mbps and 86.4 GB at 8 Mbps. Those are the raw stream figures. This calculator then adds a planning headroom of 20% by default, so the same camera is provisioned at about 25.9 GB, 51.8 GB, 77.8 GB and 103.7 GB per day respectively — headroom that absorbs scene-complexity spikes, variable-bitrate behaviour and the fact that a drive should never be run to the last byte. Two things move this number more than anything else. The first is the codec: the same scene under H.265 or H.265+ records at materially lower bitrate than under H.264, which is why bitrate rather than megapixel count is the variable to pin down. The second is the recording schedule: motion-triggered or scheduled recording reduces the duty factor below 1.0 and scales the whole figure down with it.

For a single camera recording continuously, one terabyte holds roughly 46 days at 2 Mbps, 23 days at 4 Mbps, 15 days at 6 Mbps and 12 days at 8 Mbps. Divide by the number of cameras to get the real answer for a system: the same 1 TB drive shared across eight cameras at 4 Mbps holds under three days, which is why single-drive retention questions almost always resolve into a multi-drive or NVR-array conversation. Three caveats matter before anyone buys to these numbers. Drives are sold in decimal terabytes, so a 1 TB drive is about 1,000,000,000,000 bytes and formats to roughly 0.9 TiB of usable space. Any RAID level with parity gives up further capacity to redundancy. And a storage pool run to 100% full has no margin for a bitrate spike, which is why this calculator provisions headroom rather than quoting the raw figure. Treat the raw number as the physics and the calculator's output as the planning figure.

Using this calculator's default 20% planning headroom, continuous 24/7 recording and a 4 Mbps per-camera stream, 30-day retention needs approximately 24.9 TB for 16 cameras, 37.3 TB for 24 cameras and 49.8 TB for 32 cameras. Eight cameras on the same basis need about 12.4 TB. The relationship is linear in every input, so doubling the camera count, the bitrate or the retention days doubles the storage, and halving the duty factor with a motion or schedule-based recording policy halves it. This is why the retention requirement is worth settling before the camera specification: moving from 30 to 60 days costs exactly as much storage as doubling the camera count. Treat these as planning figures for sizing an enclosure and a drive count, not as a bill of quantities. The real design depends on the actual per-camera bitrate each model produces on the scene in front of it, the RAID level, the recording schedule and the retention policy the site is obliged to meet — and those are confirmed on a site review rather than assumed from a table.

Because the same scene at 4K with H.265+ records at roughly 8 Mbps, while the same scene at 4K with H.264 records at 16-18 Mbps. The codec generation, not the resolution, drives the storage bill — by 30-50% per generation step. The calculator carries codec-aware default bitrates per manufacturer's recording-stream estimate, which is more honest than the 'multiply megapixels by 2' shortcut most calculators use.

Compression codecs at four progressive generations. H.264 (AVC, 2003) — the workhorse for two decades; still common in older installs. H.265 (HEVC, 2013) — 40-50% lower bitrate at equivalent quality; standard in 2026-generation cameras. H.265+ (Hikvision) / Zipstream (Axis) / WiseStream (Hanwha) / Smart Codec (Dahua) — manufacturer-specific 'smart codec' overlays on top of H.265 that adapt the bitrate to scene activity (static frames drop to almost zero bitrate; busy frames spike). Another 30-40% storage reduction for typical 24/7 deployments. Always specify smart-codec-on at install — most NVRs ship with it disabled by default.

24/7 continuous is the cautious default and works for high-risk environments (banking vaults, gaming floors, critical infrastructure). For most commercial deployments, motion-triggered recording with 30-50% duty cycle is operational reality — the false-alarm filtering on modern AcuSense / WizMind / Zipstream cameras has matured to the point where motion-trigger doesn't lose meaningful evidentiary value. Business-hours recording (12 hours/day) is right for office and retail where after-hours activity is rare. The calculator's schedule selector reflects these four real patterns.

RAID-1 (mirror): usable capacity = raw / 2. Worth it for very small NVR deployments where single-drive failure must not lose footage. RAID-5 (single parity): usable capacity = (n-1)/n of raw — at 4 drives you keep 75%. The 20% default headroom in the calculator approximately covers RAID-5 plus OS overhead. RAID-6 (double parity): usable = (n-2)/n — at 6 drives you keep 67%. Recommended for >8-drive arrays where two-drive concurrent failure becomes statistically probable. ZFS / Storage Spaces with double parity: similar to RAID-6 with better recovery semantics.

When camera count exceeds 64, when integration with access control / analytics is required, when multi-site federation matters, or when the operational team needs role-based access and audit trails. A modern NVR is excellent for single-site deployments up to ~64-128 cameras with basic incident export and a small operations team. Beyond that, the limitations bite: no proper user-role granularity, weak audit logging, limited integration. VMS platforms (Genetec, Milestone, Avigilon, Axis Camera Station) solve all of those at the cost of licensing complexity, server hardware and operator training.

Because manufacturer SKUs end-of-life and lifecycle continuity is operational reality. A camera SKU's official lifecycle is typically 5-7 years post-launch; spares become expensive and visually mismatched after that. HDDs in 24/7 duty have failure rates that climb after year 5. Holding 5% camera spares and 1-2 HDD spares per NVR is cheap insurance against forced replacement-window stress.

Every camera, NVR and VMS server is a potential lateral-movement entry point into the IT estate. Mandatory baseline: (1) dedicated VLAN for cameras and NVRs, no direct internet exposure; (2) periodic firmware patching for cameras and NVRs (the manufacturer security bulletins are the primary signal); (3) strong unique credentials per camera (no factory defaults); (4) monitor for camera firmware tampering and login anomalies; (5) plan for the cyber-policy of the broader estate as part of the install, not as an afterthought. CP Plus / Hikvision / Dahua are not banned in India but specific procurement policies (US Section 889, EU restrictions in regulated estates) may apply to international clients.