Home / Guides / NVR Storage Mistakes
NVR Storage Calculation: 12 Mistakes That Leave You Short on Space
The formula behind NVR storage sizing is simple. Getting the real number right on a live job is where most of the mistakes happen — here's what actually causes a "correctly calculated" drive to run out of retention early.
The basic formula
At its core, NVR storage is a straight-line calculation:
Worked example: 8 cameras at 4 Mbps each, recording continuously (24 hours/day) for 30 days.
Total bitrate = 8 × 4 = 32 Mbps. Storage ≈ 32 × 3600 × 24 × 30 ÷ 8 ÷ 1024 ≈ 10,125 GB, roughly 9.9 TB. As a rule of thumb, one camera at a steady 4 Mbps uses close to 42 GB per day of continuous recording — useful to keep in your head for a fast sanity check on site.
That formula is correct. The problem is that a real installation almost never matches the clean inputs it assumes — and that gap is where storage runs short. Here are the mistakes that cause it, from years of seeing this go wrong on real jobs.
Where the real number goes wrong
1. Estimating bitrate from resolution alone
"4MP camera" is not a bitrate — it's a resolution. The actual bitrate a camera streams depends on codec, compression settings, scene complexity, and frame rate together. Use the camera's real datasheet bitrate (or measure it), not a resolution-to-bitrate guess.
2. Ignoring the H.264 vs. H.265 difference
H.265 typically cuts bitrate by roughly half versus H.264 for the same image quality; smart-codec variants (H.265+, H.264+) push savings further on mostly-static scenes. Calculating storage with the wrong codec assumption alone can throw your estimate off by 2x.
3. Not accounting for constant vs. variable bitrate
CBR (constant bitrate) gives a predictable, steady stream — easy to calculate. VBR (variable bitrate) fluctuates with scene activity, and can spike well above its "average" rating during motion-heavy periods. Sizing purely on an average VBR figure without margin under-sizes real-world storage.
4. Confusing motion-triggered recording with continuous recording
A camera set to motion-only recording can use a small fraction of the storage of 24/7 continuous recording — but it still streams continuously over the network either way. Mixing these two up in either direction (assuming continuous when it's motion-only, or vice versa) produces a badly wrong storage figure.
5. Ignoring the impact of frame rate
Bitrate doesn't scale linearly with fps. A camera at 15 fps typically still uses roughly 60–70% of its 30 fps bitrate, because reference (key) frames fire on the same interval regardless of frame rate. Assuming a straight half-the-fps-means-half-the-bitrate relationship undercounts storage.
6. Leaving audio recording out of the calculation
If audio recording is enabled, it adds its own bitrate on top of video — usually modest (commonly 64–128 kbps per channel) but not zero, and easy to forget entirely when sizing storage for a large camera count.
7. No margin for cameras added later
Almost every install grows. Sizing storage exactly to today's camera count, with zero headroom, means the first camera added later either shortens retention across the board or requires a hardware upgrade sooner than planned.
8. Treating advertised HDD capacity as usable capacity
Drive manufacturers label capacity in decimal terabytes (1 TB = 1,000,000,000,000 bytes); operating systems and NVR firmware typically report it in binary terabytes (1 TiB = 1,099,511,627,776 bytes). A "6 TB" drive shows up as roughly 5.45 TB usable — a real difference when you're sizing close to the edge.
9. Miscalculating usable capacity with RAID or redundancy enabled
RAID 1, RAID 5, and similar redundancy configurations trade raw capacity for fault tolerance — a RAID 1 mirror of two 6 TB drives gives you roughly 6 TB usable, not 12 TB. Size storage against the post-RAID usable capacity, not the sum of the raw drives.
10. Guessing retention days instead of confirming the actual requirement
Retention requirements often come from a client's insurance policy, a franchise standard, or local regulation — not from what "feels reasonable." Confirm the actual number required before sizing, rather than defaulting to a round figure like 30 days.
11. Ignoring how low-light and IR scenes increase bitrate
Night scenes and IR illumination introduce sensor noise, and compression works harder (and produces a larger bitrate) on noisy footage than on a clean, well-lit daytime scene. A camera calculated purely on its daytime bitrate can run meaningfully larger at night — outdoor, 24/7 cameras deserve extra margin.
12. Running the drive to 100% before it cycles
Most NVRs overwrite the oldest footage once storage fills, which is expected — but planning to use every last gigabyte before that cycle starts is fragile in practice. Leaving a small working margin keeps actual retention closer to what was promised, and is easier on the drive over time.
Use the calculator, then sanity-check it
The NVR Storage Calculator already accounts for camera count, resolution, frame rate, codec, and recording mode automatically. Run your numbers through it first, then walk through this list for anything the tool can't see on its own — RAID configuration, confirmed retention requirements, and headroom for growth — before finalizing the drive you order.