A video surveillance NAS — a network-attached storage (NAS) server that records the streams from IP cameras for later review — lives or dies on two numbers: how much footage you keep (retention), and how many camera streams write to it at once. Get the sizing wrong and you either run out of space mid-month or pay for capacity you never use. This guide gives you the storage formula, the drives that survive a 24×7 recording workload, and the array layout and networking to build it on.
eRacks has built custom open-source storage since 1999, and we'll spec a surveillance NAS to your exact camera count and retention at no charge. Configure a Video NAS →
The sizing formula
Surveillance storage is just bitrate × time. Bitrate — the data rate of a video stream, measured in megabits per second (Mbps) — multiplied by the number of cameras and the number of days you keep footage (retention) gives you the raw capacity you need:
raw TB = (cameras × bitrate Mbps × 0.125 × 86,400 × retention days) ÷ 1,000,000
Working left to right:
- × 0.125 converts megabits per second to megabytes per second (there are 8 bits in a byte, and 1 ÷ 8 = 0.125).
- × 86,400 is the number of seconds in a day (60 × 60 × 24), turning MB/s into MB recorded per camera per day.
- × retention days scales it to your whole retention window.
- ÷ 1,000,000 converts megabytes (MB) to terabytes (TB).
Worked example
Take 32 cameras at 4 Mbps each, kept for 30 days:
- 32 × 4 = 128 Mbps total ingest across all cameras.
- 128 × 0.125 = 16 MB/s written continuously.
- 16 × 86,400 = 1,382,400 MB/day (about 1.38 TB/day).
- 1,382,400 × 30 = 41,472,000 MB over the retention window.
- ÷ 1,000,000 = ~41 TB raw.
That ~41 TB is raw footage only — before parity (the redundancy that lets the array survive a failed drive), filesystem overhead, and free-space headroom. Plan the actual array larger; see Retention and headroom below.
Bitrate by resolution
If your camera or video-management software (VMS) reports a fixed bitrate, use that. If you only know resolution, these ranges are reasonable starting points for H.264-encoded streams at typical surveillance frame rates:
| Resolution | Typical bitrate (H.264) |
|---|---|
| 1080p (2 MP) | ~2–4 Mbps |
| 4 MP | ~4–8 Mbps |
| 4K (8 MP) | ~8–16 Mbps |
H.265 (HEVC) — a newer codec — roughly halves these numbers for the same image quality, so a 4K H.265 stream often lands near 4–8 Mbps. Motion, scene complexity, and frame rate all move the real figure, so treat these as estimates and confirm against your camera's actual configured bitrate before you buy drives.
Why a surveillance NAS is not a general NAS
A general-purpose NAS sees bursty, mixed read/write traffic. A surveillance NAS sees something very different: constant, sequential writes, 24 hours a day, from many streams at once. Every camera is appending to disk all the time, and the array essentially never stops writing. That sustained write duty cycle is the single most important thing to design around — it dictates both the drives you choose and the array layout.
Surveillance-rated CMR drives only
Use drives purpose-built and warrantied for 24×7 surveillance, and use CMR drives exclusively. CMR (conventional magnetic recording) writes tracks side by side so any sector can be overwritten directly. SMR (shingled magnetic recording) overlaps tracks like roof shingles to pack in more capacity, but overwriting then forces slow read-modify-rewrite cycles — which is exactly the wrong behavior for a drive that is being written to continuously. Never use SMR in a surveillance array.
The surveillance-rated CMR lines to look at:
- Seagate SkyHawk and SkyHawk AI — rated for 24×7 recording and many concurrent HD streams; the AI variant is tuned for deep-learning/analytics workloads on the NVR (network video recorder).
- Western Digital WD Purple and WD Purple Pro — likewise rated for always-on surveillance write workloads, with the Pro line targeting larger, multi-stream and analytics deployments.
What you're paying for in these lines is a higher workload rating (the sustained terabytes-written-per-year the drive is designed to handle), firmware tuned for sustained sequential writes and many simultaneous streams, and — again — guaranteed CMR, never SMR. Desktop drives are not rated for this duty cycle and will wear out early under it. We won't quote specific per-model capacities or prices here, since both move constantly; eRacks will match the current best-value surveillance-rated drive to your build.
ZFS layout for video
We recommend ZFS — the open-source OpenZFS filesystem — for surveillance storage because its checksums and parity protect months of footage against silent corruption and drive failure.
- RAIDZ2 is the default. RAIDZ2 is a double-parity layout: the array survives any two simultaneous drive failures. For most surveillance arrays it's the right balance of usable capacity and resilience.
- RAIDZ3 for very wide arrays. On wide vdevs — a vdev, or virtual device, is the group of disks ZFS treats as one unit — triple-parity RAIDZ3 buys extra safety margin, which matters because resilver (the rebuild that runs after a failed disk is replaced) takes longer on big, full surveillance drives.
We won't repeat the full layout decision tree here — for mirrors vs. RAIDZ vs. dRAID and the supporting hardware (IT-mode HBA, ECC memory), see the dedicated ZFS Layout guide.
Networking for many camera streams
Dozens of simultaneous inbound streams add up. The 32-camera example above is only ~128 Mbps of ingest, which a single gigabit link can carry — but larger deployments, 4K fleets, retention re-streaming, and review traffic quickly justify faster networking:
- 10GbE for most multi-camera deployments and 4K fleets.
- 25GbE for large installations or heavy concurrent review/export.
- 100GbE for campus-scale aggregation or central archive nodes pulling from many recorders.
Size the network to peak ingest plus concurrent playback/export, not just the recording average.
Retention and headroom
Your raw footage number is a floor, not the array size. Build in margin:
- Keep ~20% free. ZFS (like most filesystems) slows down and fragments when it runs near full — leave roughly 20% headroom.
- Account for parity overhead. Usable capacity is less than raw drive capacity once parity is allocated (two drives' worth in RAIDZ2, three in RAIDZ3).
- Plan for growth. Cameras get added and resolutions get upgraded; size for where the deployment is heading, not just today.
A practical rule: take your raw footage figure, add parity overhead for your chosen layout, then size the usable pool so the footage fits inside ~80% of it.
Let eRacks spec it for you
Tell us your camera count, resolution/bitrate, and retention target and we'll size the array, pick surveillance-rated CMR drives, set the ZFS layout, and match the networking — at no charge. Every eRacks Video NAS is built on the same ZFS-friendly foundation as our storage line: IT-mode HBA, ECC memory, and CMR drives only.
Configure your eRacks Video NAS → · Video NAS overview →
Frequently asked questions
How much storage do I need for a video surveillance NAS?
Multiply cameras by bitrate by retention: raw TB = (cameras × bitrate in Mbps × 0.125 × 86,400 × retention days) ÷ 1,000,000. For example, 32 cameras at 4 Mbps kept for 30 days is 32 × 4 = 128 Mbps, which is 16 MB/s, or about 1.38 TB per day, totaling about 41 TB of raw footage. That figure is before parity, filesystem overhead, and free-space headroom, so build the array larger.
What bitrate should I use to size camera storage?
Use your camera's configured bitrate if you know it. As a rough guide for H.264 streams: 1080p is about 2 to 4 Mbps, 4K is about 8 to 16 Mbps, and H.265 (HEVC) roughly halves those numbers for the same image quality. Motion, scene complexity, and frame rate move the real figure, so confirm against the camera's actual setting before buying drives.
Why is a surveillance NAS different from a regular NAS?
A surveillance NAS sees constant, sequential writes 24 hours a day from many camera streams at once, rather than the bursty mixed traffic of a general NAS. That sustained write duty cycle dictates both the drives you choose and the array layout, which is why surveillance storage is designed differently.
Which hard drives are best for video surveillance?
Use drives rated for 24×7 surveillance and use CMR (conventional magnetic recording) only. The surveillance-rated lines are Seagate SkyHawk and SkyHawk AI, and Western Digital WD Purple and WD Purple Pro. They offer a higher workload rating and firmware tuned for sustained writes and many concurrent streams, and they are CMR, never SMR (shingled magnetic recording), whose read-modify-rewrite behavior is wrong for continuous recording.
What ZFS layout should I use for a video NAS?
RAIDZ2 (double parity, surviving any two simultaneous drive failures) is the default for most surveillance arrays, balancing usable capacity and resilience. For very wide vdevs use RAIDZ3 (triple parity) for extra margin, since resilver (the rebuild after a failed disk is replaced) takes longer on big, full surveillance drives. See the ZFS Layout guide for the full decision tree.
How much extra capacity should I plan beyond raw footage?
Your raw footage figure is a floor, not the array size. Keep roughly 20% of the pool free so the filesystem does not slow down or fragment, account for parity overhead (two drives' worth in RAIDZ2, three in RAIDZ3), and plan for growth as cameras and resolutions are added. A practical rule is to size the usable pool so the footage plus parity fits inside about 80% of it.
Machine-readable version of this guide: Open Knowledge Format bundle.
eRacks Open Source Systems