Lead Forensics

Call Us Now +44 (0) 20 3475 5743

How do you size a server for an HD surveillance system?

  • Posted by: admin

To size a server for an HD surveillance system, you need to calculate the total bandwidth generated by all cameras, determine how many days of footage must be retained, and then match those figures to hardware with sufficient processing throughput and storage capacity. The right specification depends on camera resolution, frame rate, compression format, and the number of concurrent streams the server must handle. The sections below answer the most common sizing questions in detail, from storage calculations to RAID selection and multi-server architecture.

What factors determine how much storage a surveillance server needs?

Storage requirements for a surveillance server are determined by four variables: the number of cameras, the bitrate each camera generates, the number of days of footage that must be retained, and whether motion-triggered or continuous recording is used. Multiply the total daily data volume by the required retention period to arrive at your raw storage figure, then add headroom for RAID overhead.

Bitrate is the single biggest driver. A camera streaming at 4 Mbps continuously for 24 hours generates roughly 43 GB per day. Multiply that across 64 cameras with a 30-day retention requirement and you are looking at approximately 82 TB of raw data before any RAID overhead is applied. RAID 6, for example, typically consumes the equivalent of two drives in parity, so your usable capacity will be lower than the headline drive total.

Other factors that influence storage sizing include:

  • Compression format: H.265 produces roughly half the file size of H.264 at equivalent quality, dramatically reducing storage demand
  • Scene complexity: Busy environments with constant motion generate higher average bitrates than static scenes
  • Frame rate: Recording at 15 fps rather than 25 fps cuts storage consumption significantly without sacrificing forensic value in many applications
  • Motion-based recording: Recording only on motion can reduce storage use by 50 to 80 percent in low-activity environments, though it introduces risk in high-traffic areas

Always calculate storage based on realistic average bitrates rather than maximum camera specifications. Camera manufacturers publish peak bitrates; actual recorded bitrates in typical scenes are usually 30 to 50 percent lower.

How does camera resolution affect server performance requirements?

Higher camera resolution increases the data throughput a server must sustain, raising demands on both the CPU and the storage subsystem. A 4K camera at 30 fps can generate three to four times the bitrate of a 1080p camera at the same frame rate, meaning a server handling 64 x 4K streams needs substantially more processing headroom than one handling 64 x 1080p streams.

Resolution affects the server in two distinct ways. First, the recording engine must ingest, decode, and write a much larger continuous data stream to disk without dropping frames. Second, if the server is also running video analytics, higher resolution multiplies the GPU and CPU load required to process each frame. A server that comfortably handles 1080p analytics may become a bottleneck when the same cameras are upgraded to 4K.

This is why generic enterprise IT servers, designed for transactional workloads, frequently underperform in HD surveillance environments. Surveillance servers need to sustain high-throughput sequential writes continuously, 24 hours a day, without the degradation that affects conventional hardware over time. Purpose-built surveillance hardware uses enterprise-grade drives rated for always-on operation, hardware-accelerated RAID controllers, and storage arrays optimised specifically for sequential video writes rather than the random read-write patterns typical of database servers.

What is the difference between recording servers and viewing workstations?

A recording server is responsible for ingesting camera streams, encoding or transcoding video, and writing data continuously to storage arrays. A viewing workstation decodes stored or live video and renders it on screen for operators. These are fundamentally different workloads, and combining them on a single machine in large deployments creates performance conflicts that result in frame drops or sluggish playback.

Recording servers prioritise sustained disk write throughput, network bandwidth, and CPU headroom for stream management. They typically run headless, without a display output, and are housed in rack-mounted chassis in a server room or comms cabinet. Their storage arrays are built for continuous sequential writes across dozens or hundreds of simultaneous streams.

Viewing workstations, by contrast, prioritise GPU performance for smooth multi-stream decoding and display rendering. Operators using a video management system (VMS) to monitor 16 or more live feeds simultaneously need a workstation with a capable graphics card and sufficient RAM to decode and render high-resolution streams without lag. Adding a heavy recording workload to the same machine degrades both functions.

In smaller installations of fewer than 16 cameras, a single well-specified machine may handle both roles acceptably. In enterprise deployments, separating recording and viewing functions is best practice and produces a more resilient, scalable architecture.

How do you calculate the right number of camera streams per server?

The number of camera streams a surveillance server can handle is determined by its aggregate write throughput, measured in megabytes per second, and the total bitrate of all connected cameras. Divide the server’s sustained write throughput by the average bitrate per camera to get a theoretical maximum, then apply a 20 to 30 percent headroom buffer to ensure stable operation under peak load.

For example, a server capable of sustaining 500 MB/s of disk write throughput, with cameras averaging 8 Mbps (1 MB/s) each, could theoretically handle 500 streams. In practice, after applying a 25 percent headroom buffer for analytics processing, VMS overhead, and burst traffic, a more realistic figure is around 375 streams. Camera count calculations must always account for the VMS platform’s own overhead, which varies between products.

Several additional variables affect the practical stream count:

  • Analytics workloads: Running video analytics on-server significantly increases CPU and GPU demand, reducing the number of streams the hardware can support
  • Simultaneous playback: If operators frequently retrieve archived footage while recording is active, the storage subsystem must handle both read and write operations concurrently
  • Network interface capacity: The server’s network throughput must be able to receive all camera streams simultaneously without becoming a bottleneck before data even reaches the storage layer
  • VMS licensing tiers: Some VMS platforms impose their own stream limits per server instance, which may cap your design below the hardware’s physical limit

Tools that simulate the full camera network before physical deployment, such as Secure Logiq’s proprietary Logiqal Benchmark utility, allow system designers to stress-test server configurations virtually, validating throughput limits against exact camera resolutions, frame rates, and analytics workloads before a single piece of hardware is ordered.

What RAID configuration should a surveillance server use?

For HD surveillance servers, RAID 5, RAID 6, or RAID 60 are the most appropriate configurations depending on the scale of the deployment and the level of redundancy required. RAID 5 tolerates a single drive failure, RAID 6 tolerates two simultaneous drive failures, and RAID 60 combines the performance of RAID 0 striping with the dual-parity protection of RAID 6 across multiple drive groups, making it suitable for very large storage arrays.

RAID 1 (mirroring) is well suited to the operating system drives, where protecting the OS from drive failure is critical, but it is inefficient for primary video storage because it halves usable capacity. RAID 5 offers a better balance of capacity and resilience for medium-sized arrays, while RAID 6 is preferred for large arrays where the rebuild time after a drive failure is long enough that a second drive failure during rebuild becomes a realistic risk.

Beyond the RAID level itself, two additional features are essential in a well-specified surveillance server:

  • Hardware-accelerated RAID controllers: Software RAID imposes significant CPU overhead. A dedicated hardware RAID controller with a battery-backed write cache sustains higher throughput and protects data during unexpected power loss
  • Hot-spare drives: A pre-configured hot spare allows the RAID array to begin rebuilding automatically the moment a drive fails, minimising the window of reduced redundancy without requiring manual intervention

Operating system isolation is equally important. Placing the OS on a separate pair of SSDs in RAID 1, completely independent of the primary video storage array, prevents OS drive degradation from affecting recording continuity and vice versa.

When should you use multiple servers instead of one large server?

You should use multiple servers when a single server cannot handle the total camera count, when physical site distribution makes centralised recording impractical, when your resilience requirements demand that no single point of failure can take down the entire system, or when different parts of the installation have fundamentally different performance requirements.

Large-scale deployments across multiple buildings, floors, or sites almost always benefit from a distributed server architecture. Placing recording servers closer to camera clusters reduces the network bandwidth required to transport video across the wider infrastructure and limits the blast radius of any individual hardware failure. If one server goes offline, only the cameras connected to it are affected rather than the entire system.

There are also performance-driven reasons to distribute workloads across multiple servers:

  • Analytics segregation: Running GPU-intensive video analytics on a dedicated analytics-optimised server prevents that workload from competing with recording throughput on the primary storage server
  • Tiered storage: A short-term, high-performance recording server can feed footage to a secondary long-term archive server, balancing cost and performance across the retention period
  • High-availability failover: Two servers configured in a failover pair provide automatic redundancy, with one taking over the other’s workload if a hardware fault occurs

The decision between a single large server and a distributed architecture should always be validated against the specific VMS platform in use, as different platforms handle distributed recording differently. A pre-deployment design review that models bandwidth, storage, and failover scenarios across the proposed architecture will identify the most efficient configuration before any hardware is committed.

How Secure Logiq helps you size an HD surveillance server correctly

Secure Logiq manufactures purpose-built HD surveillance servers and provides a consultative pre-sales engineering service specifically designed to take the guesswork out of server sizing. Rather than leaving integrators and IT consultants to work through calculations manually, Secure Logiq’s in-house design team analyses the complete system architecture and delivers a validated, performance-guaranteed specification. Key elements of the service include:

  • Logiqal Benchmark: A proprietary simulation tool that virtually deploys the entire camera network, stress-testing server and storage throughput before any hardware is ordered
  • End-to-end system analysis: Identification of hidden bottlenecks in standard specifications and optimised alternative configurations that reduce rack footprint, power consumption, and total cost
  • Performance guarantees: Secure Logiq formally guarantees storage retention times and system throughput for every engineered design it proposes
  • Tender-ready documentation: Detailed bandwidth and storage calculation reports, system schematics, and technical responses structured to support formal RFP submissions
  • Five-year next-business-day onsite warranty: All enterprise servers are backed by comprehensive coverage including chassis, power supplies, RAID controllers, and storage drives

If you are specifying an HD surveillance system and want a validated server architecture rather than a best guess, contact the Secure Logiq design team to request a free pre-sales consultation and system sizing review.

Related Articles