Surveillance storage breaks the rules other storage lives by. A video management system never stops writing: every camera streams continuously, all day, every day, and the server has to absorb that relentless inbound flow while keeping weeks or months of footage available and occasionally serving it back for review. The sizing maths is unusually deterministic, because it is driven by camera count, bitrate and retention rather than guesswork, but the write profile is brutal and the wrong drives or layout will fail under it. This is how to size and build a CCTV and VMS storage server for UK deployments, from the retention sum to the hardware that survives continuous writing.
The retention maths is the starting point
Surveillance capacity is one of the few storage problems you can calculate directly. Multiply the number of cameras by the bitrate each one streams, by the hours per day they record, by the retention period you must keep, and you have your raw capacity before redundancy. A higher-resolution camera at a higher frame rate produces a bigger stream; motion-only recording cuts the total but makes it less predictable; and the retention period, often set by policy or regulation, is the multiplier that dominates the result.
Because the inputs are concrete, the output is too: this is engineering, not estimation. The discipline is to be honest about the inputs, especially retention, which UK organisations frequently underestimate, and to add headroom for more cameras and longer retention later, since surveillance estates almost always grow. Settle the retention sum first, then design the hardware to carry it with room to spare.
Continuous write is the defining workload
The signature of VMS storage is sustained, parallel, sequential writing that never pauses. Dozens or hundreds of camera streams land at once, all day, so the server must sustain a high aggregate write rate indefinitely, with only occasional read traffic when someone reviews footage. This is the opposite of a transactional workload, and it punishes hardware chosen for bursts rather than endurance.
It also dictates the drives. Surveillance and nearline-class hard drives are designed for exactly this continuous-write, always-on duty cycle, unlike desktop drives that assume idle time, and the array layout must sustain the write rate without the parity overhead choking it. The combination of the right drive class and a write-friendly layout is what keeps a VMS server healthy under a load that would wear out the wrong components quickly.
- •Workload is sustained parallel sequential writes, 24/7, with only occasional reads for review
- •Use surveillance or nearline-class drives rated for continuous-write, always-on duty cycles
- •Choose a layout that sustains the write rate without parity overhead becoming the bottleneck
- •Add headroom: surveillance estates grow in cameras, resolution and retention period
Drives, layout and the controller path
Size the array for capacity and for sustained write throughput together. On the large-capacity drives surveillance uses, favour a redundancy scheme that survives a second failure during the long rebuild a multi-terabyte drive demands, because a rebuild that runs for many hours while writes keep pouring in is a vulnerable window you do not want to be single-parity through. The controller or host bus adapter should present drives cleanly and not become a bottleneck under the constant write stream.
Keep the boot and the VMS application on their own devices, separate from the recording pool, so an operating-system or boot fault never threatens the footage and rebuilds stay simple. Build the recording pool from surveillance-grade drives and the right controller path using parts from our host bus adapters range, sized so the array comfortably exceeds the aggregate inbound write rate with the cameras you have plus the ones you will add.
Network, ingest and retention policy
The camera network and the storage server are two halves of one system. The aggregate inbound stream from all cameras must traverse the network to the recorder, so the link to the server has to carry the full bitrate of every camera at once with headroom, which for larger estates means 10GbE or more rather than a single saturated gigabit link. Size the path to the cameras and to any review clients on server-grade adapters from our network cards range.
Retention policy then governs the lifecycle: footage ages out as new recordings overwrite the oldest within the retention window, so the capacity sum must hold the full window at the configured quality. Where regulation or investigation requires it, some footage may need to be exported and preserved beyond the rolling window, which is a separate, longer-retention concern that should not be served by overfilling the live recording pool.
Putting a surveillance server together
For most UK CCTV and VMS deployments this lands on a storage-dense chassis filled with surveillance or nearline-class drives in a write-tolerant redundant layout, a separate boot and application device, enough memory and CPU for the VMS to handle the stream count, and a network link sized to the aggregate camera bitrate with growth headroom. The capacity follows the retention sum directly; the drive class and layout follow the continuous-write duty cycle.
We design these continuous-write storage servers, sizing capacity from the retention maths and selecting drives and the controller path for the always-on workload, in our server configuration service, building larger estates out on dense platforms from the Dell storage range. The result is a recorder that keeps writing every camera, every day, for the full retention period, with room to grow as the estate does.