NVR Storage & Retention Calculator

What it calculates

Storage for surveillance recording is a bitrate problem before it is a capacity problem. One megabit per second sustained for a day writes 10.8 GB, so the arithmetic starts from the aggregate stream of the estate and works outwards to drives.

• Per-camera bitrate, recommended from resolution, frame rate and codec, or entered directly
• Aggregate stream in Mbps, and the write and read load in MB/s
• Total capacity for a retention period, or the retention a given capacity yields
• Recording duty cycle, for sites that record on motion rather than continuously

Why it sizes the chassis, not just the capacity

An array can hold the footage and still fail to record it. Drives have a sustained throughput ceiling and parity multiplies the cost of every write, so a system sized only on terabytes can meet the capacity target and drop frames in service. Each chassis class is checked against bandwidth and IOPS as well as capacity, and a row that fails either says so.

• Drive count and drive size per chassis class, 8-bay through 60-bay
• RAID 5 and RAID 6 side by side, with the write penalty applied
• Bandwidth headroom in MB/s and IOPS headroom against the workload
• The network interface the aggregate stream actually needs

What it will not tell you

Bitrate varies with scene complexity, lighting and motion. A busy forecourt at night can run well above what any bitrate table predicts, and a static corridor well below. Treat the result as a sizing baseline and let a survey settle the margin.

Start from bitrate, not from terabytes

Surveillance storage is a bitrate problem before it is a capacity problem. Each camera produces a continuous stream measured in megabits per second, and one megabit per second sustained for a full day writes 10.8 GB. Multiply by the camera count and the retention period and you have the capacity — everything else is refinement.

This is why two sites with the same number of cameras can need wildly different arrays. Thirty-two cameras at 1080p and 15 fps on H.265 produce a fraction of what the same thirty-two produce at 4K and 25 fps. The camera count is the least informative number in the specification.

• Resolution sets the base bitrate — but not linearly. Compression improves as resolution rises, so a 4K stream is not four times a 1080p stream.
• Frame rate scales it. Halving the frame rate roughly halves the bitrate, though real encoders are a little less generous than that.
• The codec multiplies it. H.265 typically costs about two-thirds of H.264 for the same picture; MJPEG, which has no inter-frame compression at all, costs several times more.
• Scene content moves it further than any of the above. A static corridor compresses far better than a busy forecourt at night.

Recording duty is the number most estimates get wrong

Very few sites record continuously. Motion-triggered and schedule-based recording is the norm, and it scales storage linearly: a thirty-day retention policy at forty per cent duty holds twelve days' worth of footage, not thirty.

Ignoring this over-quotes almost every job. It is also the easiest figure to get badly wrong in the other direction — an entrance camera on a busy street may be recording nearly all day, whatever the policy says. Where the estate is mixed, size the always-on cameras separately from the triggered ones.

Capacity is not the only thing that can fail

An array can hold the footage and still fail to record it. Every drive has a sustained throughput ceiling, and parity multiplies the cost of each write — RAID 5 turns one write into two reads and two writes, RAID 6 into three of each. A system sized purely on terabytes can meet the capacity target and drop frames in service, which is the failure nobody notices until the footage is needed.

That is why the configurations here are checked against throughput and IOPS as well as capacity, and why an option that fails either is marked rather than quietly ranked below the others.

• Write load is the aggregate stream divided by eight, in megabytes per second.
• Playback adds read load on top — reviewing footage while recording continues is normal, not exceptional.
• Rebuild is the worst case. A degraded array is still recording while it reconstructs a failed drive, and that is precisely when headroom matters.

Choosing the chassis size

The right chassis is the smallest one that holds the drives the job needs. A configuration of three drives belongs in an eight-bay enclosure, not a sixteen-bay one — the extra bays are paid for and never used, and they do not make the array any faster or any safer.

That cuts both ways. Where a requirement genuinely exceeds what twenty-four bays can hold, a larger enclosure is the correct answer rather than two smaller ones: one chassis, one set of controllers, one thing to manage. We build from eight bays to sixty in a single enclosure, and only past that does a deployment become genuinely multi-node.

A long retention period is what usually pushes an estate over that line. Sixty-four cameras at 5MP and 25 fps kept for six months needs close to 600 TB — a modest camera count and a substantial array, because retention multiplies everything.

A note on drive choice

Surveillance recording is a sustained, write-heavy workload that overwrites the oldest footage on a retention cycle, and it runs unattended for years. Drives intended for that duty cycle are rated for it; desktop drives are not, and neither are the very largest capacities on the market, which use recording technologies unsuited to constant rewriting.

The capacities offered here are the ones that suit the workload. If a supplier quotes something outside that range for a recorder, it is worth asking why.