NVR Storage Planning for IP Camera Projects: 2026 Math

Leo · 2026-10

NVR storage planning for IP camera projects means calculating total capacity from camera count, bitrate, and retention days before any hardware is quoted. The working formula is GB = cameras × bitrate (Mbps) × 10.8 × retention days, and a 12-camera site at 4 Mbps with 30-day retention needs roughly 15.6 TB before RAID overhead. Get these four numbers fixed first, and the rest of the bill of materials follows.

The term itself is narrow but the decision behind it is not. This article is written for the systems integrator or IT manager who has to turn a camera schedule into a storage specification — someone who signs a fixed-price project and then lives with the capacity number long after handover. If you are that person, the risk you are carrying is not camera selection; it is under-sizing the recorder and eating the change order later.

The core definition worth fixing early: an NVR (network video recorder: a device that receives IP camera streams over Ethernet, writes them to local disks, and serves recorded video back to operators) sets the storage floor for a project. The published retention tiers on an edge-AI recorder such as the products/s1-security-kit — 7 days, 14 days, or 30 days — exist precisely because retention choice, not camera count, usually drives the storage bill. The policy side of that choice — how many days different site types actually keep — is covered in nas-video-surveillance-retention-storage-sizing.

How much storage does an IP camera project actually need?

Storage need equals camera count multiplied by bitrate, multiplied by a per-day conversion constant, multiplied by retention days — nothing else in the camera schedule changes that number.

Projects trip over this because buyers fix the camera count first and the retention period last, then discover the capacity line item moved by a factor of four. The table below shows how the same site scales with retention. Bitrates are the reader’s own project variables; the constants are arithmetic, not vendor specifications.

The first row is deliberately the smallest and the last row the largest, because the arithmetic is what a buyer should test against their own schedule. A 32-camera site doubles its capacity requirement the moment someone raises bitrate from 4 Mbps to 8 Mbps (41.5 TB to 82.9 TB, by the same formula). Extending retention to 90 days rather than 30 triples it again: 32 × 4 × 10.8 × 90 = 124,416 GB, or about 124.4 TB at 4 Mbps and about 248.8 TB at 8 Mbps.

This is the first place where a stored, self-contained fact beats a brochure claim: the published capacity ceilings of the platforms you might deploy set the hard boundary. woCyber publishes a 120 TB ceiling on its four-bay platform and a 60 TB ceiling on its dual-bay platform, so the campus and distribution-center rows above sit inside a single four-bay unit only at the lower bitrate.

Four numbers to lock before requesting a quote

Four numbers decide the storage specification: camera count, sustained bitrate per camera, required retention days, and the RAID level the client will accept. Change any one and the quote changes.

Integrators who scope NVR storage planning for IP camera projects professionally treat these as a signature-ready block, not a conversation; the quoting workflow on the cctv-storage-appliance-oem-for-integrators side follows the same discipline. The reason is that each number maps to a different cost driver.

• Camera count sets the ingest load and the number of PoE ports or switches in scope.
• Bitrate per camera is the multiplier most often left vague; it varies with resolution, frame rate, and codec.
• Retention days is the linear scaling factor, and it is usually set by policy, not by budget.
• RAID level determines usable capacity versus raw capacity — the gap buyers forget.

Codec choice changes bitrate materially for the same visual result. H.265 (also written HEVC: a video compression standard that reduces bitrate for the same picture quality compared with older H.264) is specified in ITU-T Recommendation H.265. A procurement team that fixes resolution and frame rate but leaves codec open is effectively leaving the capacity line item open.

RAID overhead and the drive count it changes

RAID overhead means raw capacity is always larger than usable capacity, so the drive count a project needs is driven by usable capacity divided by the per-drive capacity after accounting for parity.

Integrators get caught when they quote drives against the raw number. A four-drive RAID 5 array built on 8 TB drives delivers roughly 24 TB usable (three data drives plus one parity drive), not 32 TB. For the 15.6 TB office-and-warehouse example above, that means a four-drive array with comfortable headroom; for the 41.5 TB campus example, it means a larger drive set or a higher density platform.

The parity cost is why capacity ceilings are quoted separately from drive bays. A platform that publishes a 120 TB ceiling and four bays is telling the integrator how much raw storage the chassis will take — the usable figure still depends on the RAID level chosen. Where a project needs both surveillance retention and general file storage on one box, a single appliance that pools both workloads removes the second box and its idle capacity.

Does edge AI filtering lower the storage requirement?

Edge AI filtering does not lower the storage requirement for continuous recording — the encoder writes the same bytes whether or not classification is accurate. What it changes is how much of the archive an operator actually has to review.

Vendors blur this line more often than they should. A camera that records continuously writes the same number of bytes regardless of classification quality; the value edge AI adds is searchable, structured video and fewer hours spent scrubbing timelines by hand.

The published specification for the woCyber S1 states a false-alarm rate below 3 percent, with people, vehicle, and pet categories classified on the device itself, and all computation happening 100 percent locally rather than in a vendor cloud. For an integrator, the local-computation point is a procurement fact, not a marketing line: a system that processes video on the device does not depend on a third-party cloud subscription to keep functioning.

Consider a hypothetical 50-person manufacturing operation that runs 16 cameras and currently pays a recurring cloud-camera subscription per camera. If the client’s policy requires 30-day retention at 4 Mbps per camera, the raw requirement is roughly 20.7 TB before RAID (16 × 4 × 10.8 × 30 = 20,736 GB) — a figure that immediately narrows which recorder classes qualify. The woCyber S1 publishes 7/14/30-day retention tiers and per-account isolation, and keeps the footage on premises instead of paying per camera each month; which recorder class carries 20.7 TB is a quote-time decision, driven by the number this formula produced. The trade-off the client accepts is that they, not the vendor, own disk replacement and backup discipline.

The signing-day capacity math, step by step

The single calculation worth running is the retention formula with the client’s own numbers substituted, and then a second pass at the next retention tier up.

Use GB = cameras × bitrate (Mbps) × 10.8 × retention days. The constant 10.8 converts megabits per second into gigabytes per day (86,400 seconds ÷ 8 bits per byte ÷ 1,024 MB per GB). Worked example: 12 cameras × 4 Mbps × 10.8 × 30 days = 15,552 GB, or about 15.6 TB raw. Add RAID 5 parity on a four-drive array and the usable figure lands near 24 TB on 4 × 8 TB drives — which would leave headroom if the client later raises retention to 45 days — 12 × 4 × 10.8 × 45 = 23,328 GB, about 23.3 TB raw, still inside the usable figure of that example array.

Two checks belong next to that number. First, confirm the codec actually deployed; if the site runs H.265, the effective bitrate for the same quality is lower than an H.264 plan, and the capacity figure above can be cut materially. Second, confirm the retention policy in writing, because a verbal “about a month” is what turns into a change order at handover. In practice, the argument that costs integrators money is not the formula itself — it is agreeing to a retention tier the client never wrote down, then discovering at handover that the policy actually calls for 90 days and the chassis cannot hold it.

How do ONVIF and PoE reduce installation cost?

ONVIF and PoE reduce installation cost by removing proprietary pairing steps and separate power runs: cameras that conform to ONVIF profiles interoperate across vendors, and PoE carries both data and power on one cable.

ONVIF (Open Network Video Interface Forum: an industry body publishing interoperability profiles for IP video products) maintains its profile specifications at onvif.org/profiles. From a storage-planning standpoint, the value is that the recorder can adopt cameras over the network rather than requiring a matched-vendor set, which protects the client from lock-in and protects the integrator from single-source risk.

PoE (Power over Ethernet: delivering electrical power and data over the same Ethernet cable) removes one run of cabling per camera and, more importantly, the electrician’s labor line that goes with it. The Ethernet standards behind the underlying data rates are maintained by the IEEE 802.3 working group. A 12-camera site that avoids twelve separate power drops removes an electrician visit per camera run from the schedule — a line item that shows up before any hardware cost.

For projects that need both local video retention and file storage under one appliance, a combined platform avoids buying two boxes. The woCyber A2 Pro pairs two drive bays and RAID 1 with ONVIF and PoE camera support alongside general network storage, which suits sites that want one device to serve both functions rather than a recorder plus a separate NAS.

Shipping day: what to have in writing

Before the first unit ships, verify three things in writing: the retention configuration, the interoperability profile the cameras use, and the compliance documentation the project requires.

The reason this belongs in the planning stage rather than at delivery is that all three can block acceptance. A recorder that supports ONVIF camera onboarding but is delivered with a different default retention tier than the spec sheet may fail inspection on the day the client’s auditor arrives.

On compliance, woCyber publishes CE, UKCA, FCC, RoHS, REACH, and WEEE for its product lines, and states that deployment can be kept fully local — data stays on the client’s own device and network, with access controlled per account. Integrators specifying a project where data residency matters should confirm the deployment model in writing rather than assuming it; the deployment-stage checklist in ai-nas-security-features-to-verify-before-deployment lists the verification points worth walking through with a supplier.

The verification step is where a sourcing decision gets made real. Platforms differ most in bay count and capacity ceiling, so a shortlist should start from the retention figure the client already agreed to and work backward to the chassis that holds it; the published products page gathers those ceilings per model.