How to Size NAS Storage for Enterprise Video Surveillance

A retention gap is one of the worst ways to discover a storage system was undersized. An incident happens, someone requests footage from three weeks ago, and it turns out the array only holds two weeks of recordings because nobody recalculated capacity after the last camera upgrade. Video surveillance storage fails quietly, one overwritten day at a time, long before anyone notices the array is undersized.

The math has also gotten less forgiving. A single 4K camera generates roughly four to six times the data of a 1080p camera at the same frame rate, and according to Reolink’s storage guidance, a terabyte that holds about a month of 720p footage may only hold seven to ten days once cameras move to 4K. Multiply that across a facility running dozens or hundreds of cameras with a retention requirement measured in weeks, not days, and the difference between correct and incorrect sizing is measured in terabytes, not gigabytes.

This guide covers how NAS storage for video surveillance needs to be sized and protected differently than a general-purpose file share: capacity calculation, retention and compliance, redundancy under continuous recording, and ransomware protection for footage that may need to hold up as evidence.

Why Video Surveillance Storage Behaves Differently Than Standard File Storage

Most enterprise NAS sizing assumes a mix of reads and writes that ebbs and flows with the business day, with the array sitting mostly idle overnight and on weekends. Video surveillance storage does the opposite. Every camera writes continuously, twenty-four hours a day, seven days a week, regardless of whether anyone is watching, and that write load doesn’t taper off during off-hours the way office file traffic does.

Continuous Write Workloads and Why Standard NAS Sizing Falls Short

A NAS platform sized using typical office-hours utilization patterns will look adequate on paper and still fall short in production, because surveillance recording never gives the array a quiet period to catch up on background tasks like scrubbing, tiering, or snapshot cleanup. Sizing has to account for sustained write throughput across the full camera count at once, not an average that assumes some cameras are idle at any given moment, because in a surveillance deployment none of them ever are.

Network bandwidth needs the same all-cameras-at-once treatment. A single 4K camera streaming at 12 megabits per second seems trivial on its own, but 200 of those cameras writing simultaneously add up to roughly 2.4 gigabits per second of sustained ingest before accounting for playback, exports, or VMS overhead pulling from the same array. Undersizing the network path into the NAS produces the same symptom as undersizing the storage itself: dropped frames and recording gaps that only get discovered when someone needs the footage.

Calculating Storage Capacity for Camera Count, Resolution, and Retention

Capacity planning for surveillance storage comes down to a formula IT teams can run themselves rather than relying on a vendor’s rule of thumb: storage in gigabytes equals bitrate in kilobits per second, converted to bytes, multiplied by seconds per day, multiplied by the number of cameras, multiplied by the retention period in days. Bitrate is the variable most buyers get wrong, because it depends on resolution, frame rate, compression codec, and scene complexity, not just the camera’s advertised resolution.

The Bitrate and Retention Formula Every Storage Buyer Should Know

Running the formula against a realistic deployment shows how quickly requirements scale. A facility with 64 cameras recording at a modest 2 megabits per second, with a 30-day retention requirement, needs in the neighborhood of 62 terabytes of usable capacity before accounting for RAID or erasure coding overhead, redundancy, and headroom for future camera additions. Increase either the camera count, the bitrate, or the retention window, and that number climbs fast enough that a sizing estimate done once at deployment and never revisited becomes wrong within a year.

Recording mode changes the effective bitrate the formula should use, which is where many sizing estimates go wrong before the math even starts. Continuous recording writes at the camera’s full configured bitrate around the clock, while motion-triggered or scheduled recording can cut effective storage consumption significantly in low-activity areas, but only if the VMS is actually configured that way and only if the areas selected for motion-triggered recording are actually low-risk. Applying a motion-triggered estimate to cameras covering an entrance, a cash register, or any other high-value area is how a sizing calculation ends up technically correct on paper and dangerously wrong in the one scenario the footage was needed for.

How Resolution and Codec Choice Change Capacity Requirements

Codec efficiency changes the math as much as resolution does. H.264 compression can reduce file size by roughly 80% compared to older MJPEG encoding at the same resolution, and H.265 pushes efficiency further still, which is why two facilities with identical camera counts and resolutions can have dramatically different storage requirements depending on which codec their VMS is configured to use. The table below illustrates how differently a single camera’s daily footprint scales with resolution alone, holding bitrate assumptions from typical H.264 encoding constant.

These figures shift with scene complexity, frame rate, and codec settings, which is exactly why a real calculation using the facility’s actual camera specifications, not a generic table, has to drive the final purchase decision.

Retention Periods and Compliance Requirements for Surveillance Footage

Retention requirements are frequently set by regulation rather than internal preference, and getting this number wrong isn’t just an inconvenience, it can be a compliance failure. PCI DSS requires 90 days of retained video surveillance footage in areas where cardholder data is stored or processed, which applies to any business accepting card payments near a point-of-sale or data center location. Nevada’s gaming regulations require a minimum of seven days for routine casino floor activity and 60 days when suspicious activity has been flagged, figures that other state gaming commissions largely mirror.

Retention requirements also compound when a facility falls under more than one regulatory regime at once, such as a retail location that both accepts card payments and operates in a jurisdiction with its own local surveillance ordinance. The safest sizing approach is to identify every applicable requirement first, take the longest retention period among them, and size storage to that figure with margin, rather than sizing to the most common or most convenient number and hoping no incident falls outside the window.

Retention is only half the compliance picture. Footage that may be used as evidence also needs an export and chain-of-custody path that doesn’t compromise its integrity, meaning the storage platform should support exporting a verifiable, unaltered copy of a specific time range without giving an administrator the ability to quietly edit the original before or after that export happens. A retention policy that satisfies the day count on paper but can’t produce a defensible export when legal counsel or a regulator actually asks for it hasn’t solved the underlying compliance requirement.

RAID, Redundancy, and Drive Endurance for Continuous Recording

Drives written to continuously wear differently than drives in typical file-server duty cycles, which is why surveillance deployments should use drives explicitly rated for 24/7 write-intensive workloads rather than standard desktop or even general enterprise drives rated for lighter duty cycles. Running consumer-grade drives in a surveillance array under continuous write load is one of the most common ways a facility ends up with premature drive failures well before the expected hardware refresh cycle.

RAID and erasure coding decisions matter more under continuous recording too, because a drive rebuild competes for I/O bandwidth with live recording that cannot simply pause while the array recovers. Erasure coding schemes that tolerate multiple simultaneous drive failures, and that rebuild without materially degrading ongoing write performance, are worth prioritizing over traditional RAID levels in any surveillance deployment large enough to expect drive failures as a routine, not exceptional, event.

A short set of procurement questions surfaces whether a platform was actually engineered for this workload or just repurposed from a general file-server line:

• Are the drives being quoted rated for 24/7 surveillance or write-intensive duty cycles, or are they standard drives rated for a lighter, intermittent workload.
• What happens to live recording performance during a drive rebuild at full camera load, not an idle test configuration.
• How many simultaneous drive failures can the array tolerate before recording itself, not just data availability, is affected.
• Does the platform report drive health and predicted failure proactively, or does a failure only surface after it has already happened.

Ransomware Protection and Immutable Storage for Surveillance Footage

Surveillance footage carries a different kind of risk than a typical file share, because in an investigation or legal proceeding, the footage itself may need to hold up as evidence, which means its integrity matters as much as its availability. A ransomware attack that encrypts or deletes surveillance storage doesn’t just cause downtime, it can permanently erase the only record of an incident the footage was originally being kept to document.

Immutable, write-once storage and air-gapped backup copies address this directly by making stored footage impossible to alter or delete, even by a compromised administrator account, for the length of the required retention window. This overview of NAS security and this walkthrough of immutable snapshots for NAS both cover the mechanics of setting up write-once protection correctly, and this breakdown of ransomware-proof NAS appliances goes into the hardware and firmware layer of that same protection.

Scale-Out NAS Architecture for Growing Camera Counts

Camera counts rarely stay flat. A facility that adds a wing, a parking structure, or a new compliance requirement ends up adding cameras faster than the original storage sizing anticipated, and a fixed-capacity system built around a specific bay count forces a disruptive forklift replacement the moment it runs out of room. Scale-out NAS architecture adds capacity and throughput together by adding nodes to the cluster, so a growing camera count is met with proportionally growing write performance instead of an array straining to keep up with more simultaneous streams than it was originally sized for.

This matters specifically for surveillance because unlike a general file share, where growth might mean adding a few users, camera growth adds sustained write load immediately and permanently from the day the new cameras go live. A scale-out platform absorbs that as a planned expansion; a scale-up platform sized for the original camera count absorbs it as a bottleneck.

Multi-site organizations add another layer to this planning: a retail chain or campus with several locations often wants footage centrally accessible for a security operations team without requiring every camera stream to traverse a wide-area network link in real time. Sizing storage per site, with a scale-out platform at each location and a defined replication or retrieval path back to a central point, avoids forcing a single array to absorb write traffic from locations it was never physically near.

How StoneFly’s Video Surveillance Storage Appliances Address These Requirements

StoneFly’s video surveillance storage appliances are built specifically around the requirements above rather than adapted from a general-purpose NAS line. The appliance family spans four tiers, from entry-level configurations up to enterprise-grade systems, scaling from 8 to 108 drive bays so capacity can grow with camera count without a platform change partway through.

Data protection is built in at the platform level: WORM storage and immutable snapshots keep recorded footage from being altered or deleted within its retention window, air-gapped repository options isolate backup copies from network-based ransomware, and hardware RAID with erasure coding protects against the drive failures that continuous recording makes routine rather than rare. For organizations sizing a surveillance storage refresh against the criteria in this guide, that combination addresses capacity, redundancy, and footage integrity as one validated platform rather than three separate purchasing decisions.

Conclusion: Sizing Surveillance Storage Around What It Actually Has to Survive

Surveillance storage has to survive three things at once: a continuous write load that never gives the array a quiet period, a retention requirement that is often set by regulation rather than preference, and a threat model where losing the footage is a compliance and evidentiary failure, not just downtime. Sizing capacity using the real bitrate and camera count, confirming the longest applicable retention requirement across every regulation that applies, and building in write-intensive drive redundancy and immutable, ransomware-resistant storage from the start avoids the quiet failure mode where a system looks fine until the day someone actually needs footage that was already overwritten.

Facilities planning a surveillance storage refresh should run the actual camera count, resolution, and retention numbers before shortlisting a platform, rather than relying on a vendor’s generic sizing assumptions, and reach out to contact StoneFly directly with those specific numbers for an accurate capacity and redundancy recommendation.