Video Surveillance Server (VMS): sizing storage and load

Why size storage and load before buying a server

If a VMS server is chosen "by eye," problems usually don't appear immediately but after a few weeks. First the archive runs out of space unexpectedly, then search and playback slow down. In the worst case you get dropped recordings and choppy video during peak hours.

The main mistake is to focus only on the number of cameras and the total disk capacity. For a VMS it's more important not "how many cameras," but how much data they actually write per second and how long you need to keep it. Two 50-camera systems can differ dramatically: one might write 2 Mbps per camera, another 10 Mbps because of higher quality, FPS or a complex scene.

As a system grows the inputs almost always change. People add higher-resolution cameras, increase FPS at the entrance, enable analytics (detection, recognition), or change retention requirements. All of these increase bitrate and load on network, disks and CPU even if the camera count changes only a little.

Before procurement it helps to reduce the problem to three figures:

• Mbps — incoming recording throughput;
• TB — archive size for the required retention;
• TB/day — daily recording volume (how “heavy” the disks are).

These indicators quickly show whether a 1G network will be enough, what class of disks is needed, and how many drives are required considering usable capacity.

Minimum to fix in advance: average and peak bitrate per camera, archive depth (days) and recording mode (24/7 or event), total incoming traffic with growth margin, and TB/day to estimate disk subsystem load.

Simple example: you plan 30 cameras at medium quality today, and in six months you add 20 and raise FPS on some points. The server may hit limits not in capacity but in write speed and network. Sizing before purchase is usually cheaper than urgent drive replacement, network upgrades and archive migration later.

What inputs to collect about cameras and VMS

To get realistic sizing start not with disks and RAID but with camera parameters and VMS settings. The VMS server often "fails" because inputs ignored at the start: bitrate peaks, a second stream for viewing, or a different recording mode.

For each camera collect both datasheet values and how it will be configured on-site. Distinguish "spec maximum" from "project settings."

What to record (one table is enough):

• Resolution, FPS, codec (H.264 or H.265) and key encoding settings.
• Scene type and conditions: outdoor or indoor, lots of motion, headlights, snow, foliage.
• Bitrate control: CBR or VBR and any set limits.
• Recording mode: continuous, motion, scheduled, with pre- and post-recording.
• How many streams will actually be used: primary for archive, substream for live view, extra streams for mobile clients or video walls.

CBR is easier to plan for network: traffic is steadier and it's simpler to size ports and switches. VBR often gives better quality at the same average bitrate but brings surprises on peaks: night mode, rain, busy scenes or a flash can spike traffic and disk load.

Also clarify what the VMS does besides recording. Motion detection on the camera and detection on the server are different loads. Analytics, recognition, transcoding for remote access, encryption, and many simultaneous viewers can require more CPU/GPU and memory than the recording itself.

Practical example: in a warehouse 40 cameras record continuously, security watches 16 cameras at once, and the manager opens mobile viewing on the road. If substreams and the number of connections are not considered, the storage calculation may be correct while the network and server "choke" at peak times.

How to calculate and verify camera bitrate

Bitrate is how much data a camera actually transmits and writes per second. It directly affects network, disks and archive cost. Bitrate is not equal to resolution: two 4 MP cameras may produce different streams because of codec, FPS, compression level and scene content.

For initial estimates use typical ranges and include margin. Many teams take average bitrate for planning but size procurement by peak bitrate — otherwise the VMS server will hit network or write limits at the worst moments.

Guidelines for a "normal" image at 15–25 FPS:

• 1080p: H.264 2–6 Mbps, H.265 1–4 Mbps
• 4 MP: H.264 4–10 Mbps, H.265 2–7 Mbps
• 4K: H.264 8–20 Mbps, H.265 4–14 Mbps

Numbers can rise quickly due to the scene. Outdoor foliage, snow, rain, crowds, flickering signs, noisy night images — these make the codec work harder and increase bitrate.

The most reliable method is to measure the real bitrate with a test. Record 15–30 minutes in typical conditions and separately in worst conditions (night, snow, peak hours), then check the resulting file sizes.

Practical test:

• set the codec, resolution and FPS as planned;
• record a 15–30 minute test clip;
• divide the file size by recording time and convert to Mbps;
• repeat for a complex scene.

Also account for the substream. It is usually made lightweight (for an operator grid) so viewing doesn't saturate the channel or decoding. Archive sizing usually uses the main stream; the substream matters for comfortable monitoring and remote access.

Calculating archive size: retention depth and usable capacity

Archive volume is straightforward: average bitrate × recording time × number of cameras. Keep units consistent or you can miss by several terabytes.

Basic approach: convert Mbps to MB/s (divide by 8) and multiply by seconds. A handy rule: 1 Mbps ≈ 10.8 GB per day.

Example without complex formulas: 20 cameras at 4 Mbps, recording 24/7, retention 30 days.

• One camera: 4 × 10.8 = 43.2 GB/day.
• For 30 days: 43.2 × 30 = 1296 GB ≈ 1.3 TB per camera.
• For 20 cameras: about 25.9 TB.

Then consider differences between paper retention and real usable disk capacity. Usually account for:

• filesystem and VMS overhead (often 5–15%);
• margin for bitrate peaks (night, snow, rain, noise);
• growth margin (new cameras, higher FPS/resolution).

If recording is motion-based, don't multiply as for 24/7. Use an activity percentage. For example, 25% activity means the camera records about 6 hours per day. Prefer tested or pilot-backed values rather than optimistic guesses.

A practical minimum for capacity margin is +20–30% to cover added cameras or quality changes that make the archive fill faster than planned.

Disk and RAID requirements for stable recording

For VMS you need not just terabytes but predictable sequential write performance 24/7. The archive may be limited not by capacity but by write speed: more cameras can cause disks to fall behind, producing gaps in recording.

HDDs are usually used for archives: they are cheaper per TB and suit long continuous recording. SSDs are useful alongside the archive for OS, VMS database, indexes, cache and temporary files. SSDs speed up search and timeline scrubbing but do not replace the need to choose HDDs that sustain continuous writes.

Which RAID fits video recording

RAID choice balances capacity, resilience and rebuild time.

• RAID 5 saves space but tolerates only one disk failure. On large drives and long rebuilds the risk is higher.
• RAID 6 tolerates two disk failures and is often the calmer choice for big archives.
• RAID 10 gives high performance and fast rebuilds but halves usable capacity.

For 32–64 camera systems with planned expansion, RAID 6 or RAID 10 usually cause fewer surprises than RAID 5.

Rebuild: the hidden risk

The problem is not just that rebuilds are long. During rebuild performance drops, load on remaining disks rises, and a real "vulnerability window" appears. Typical scenario: load is already near limit, a drive fails, and while the array rebuilds the system starts losing frames during peak hours.

Plan hot spare so recovery starts immediately, enable SMART and alerts, schedule replacements by drive life, and separate roles (SSD for OS and VMS DB, a dedicated array for archive).

If you build a server platform for archive use, plan the number of drive bays, controller and spare drive capacity in advance. In rack platforms like the S200 class this is solved at configuration time so archive expansion doesn't become a risk to recording.

Network for IP cameras: estimate traffic and avoid hitting 1G

Network often becomes a bottleneck before disks. Start by summing real bitrates of cameras that record simultaneously and add margin for peaks and control traffic.

Practical rule: total incoming = sum of camera bitrates + 10–20% margin. Peaks come from complex scenes (rain, snow, crowds), day/night transitions, and temporary bursty writes from VMS buffers.

1G vs 10G: when to use which

A 1G port delivers about 900–940 Mbps of usable bandwidth. If you have 80 cameras at 8 Mbps that's 640 Mbps for recording alone. Add margin, management traffic, remote viewing, and you quickly near saturation.

If the calculated load reaches 70–80% of 1G, plan for 10G or split streams across interfaces (e.g., one port for cameras, another for users and archive exports). It's usually easier than fixing dropouts later.

VLANs and uplinks: common throughput losses

A separate VLAN for cameras isolates broadcast noise, reduces accidental loops and simplifies access rules.

Frequent causes of network slowdowns: gigabit uplinks between floors with many cameras, limited switch backplane capacity, cameras and office PCs on the same network without segmentation, multiple remote viewers requesting max quality, and archive exports during working hours over the same links as recording.

Example: security watches 16 cameras at 4 Mbps each — that's +64 Mbps. It seems small but when you are tight on a 1G link such additions cause stutters and frame loss.

Server load: CPU, RAM, GPU and VMS features

VMS load is typically split into recording and viewing. Recording loads disks and network (server accepts streams and writes archive). Viewing, especially with many operators, stresses CPU and sometimes GPU because streams must be decoded and rendered.

CPU is loaded not by cameras themselves but by what the VMS does with streams. If the server just accepts H.265 and writes to disk, CPU use can be moderate. Turn on processing and the picture changes.

Common CPU-heavy tasks: mass decoding for live view and video walls, transcoding for remote access, server-side analytics, encryption and watermarking, and database/index maintenance.

GPU is not always necessary. It helps when many concurrent high-res views are decoded, when H.265 is heavily used (decoding is heavier), or when analytics supports GPU acceleration. If the server only records and rarely shows 1–2 channels, a discrete GPU is often unnecessary.

RAM and the system disk matter because of the VMS "internal kitchen." Database, logs, indexes, frame cache and services should be on SSD separate from the archive. A slow or full system disk can make the VMS sluggish even if the archive disks are fine.

Another common oversight is the number of simultaneous clients. Four operators each viewing 16 cameras equals dozens of streams to decode. Substreams and limiting operator FPS often have a greater effect than simply adding CPU.

Step-by-step sizing: from cameras to server configuration

To pick a VMS server without surprises follow this route: camera parameters → disks and archive → network → compute. This makes it clear where to add margin and where you'd overspend.

Procedure:

1. Fix camera and recording parameters: resolution, FPS, codec (H.264/H.265), VBR or CBR, 24/7 or event recording, audio, and secondary streams.

2. Calculate total bitrate: sum average bitrates and add 20–30% for peaks (snow, rain, crowds, night). For VBR this is critical.

3. Convert bitrate to archive: multiply total stream (Mbps) by daily seconds and by retention days. If some cameras are event-based, account for them separately.

4. Choose RAID and compute usable capacity: don't confuse raw disk volume with usable capacity after RAID and reserves. At the same time check whether the disk subsystem can sustain continuous writes.

5. Check the network: will 1G uplinks suffice, how many ports, where are PoE switches, and will there be bottlenecks between cameras, server and operator workstations?

6. Assess compute: viewing, transcoding, server detection and analytics load CPU/GPU and RAM. If many concurrent viewers or analytics are planned, include CPU and memory margin and consider GPU for heavy tasks.

Mini-scenario: 40 cameras at 6 Mbps ≈ 240 Mbps, with margin ≈ 300 Mbps. Here check uplinks and disk subsystem, not only TB. For such loads rack servers with many drives and stable recording (e.g., S200 class) are typical choices.

Common mistakes when scaling cameras

Systems are often designed by datasheet numbers but must operate in real conditions. When cameras increase any small error in estimates turns into a full archive, playback stalls and lost frames.

Typical mistakes:

• Using datasheet bitrate without checking night mode. Noise, gain and headlights at night often raise bitrate 1.5–3×.
• Counting disk capacity by sticker value. RAID consumes space, filesystem reduces usable TB, and VMS needs overhead.
• Planning retention with no margin. Cameras are added over time or FPS/resolution increases. Capacity and throughput margin is normal practice.
• Forgetting remote viewing and archive export during working hours. These add read load and network traffic, and recording can stall at peak times.
• Overestimating RAID 5 on large drives. Rebuilds may be long and reduce speed, increasing risk of a second failure.
• Running recording and heavy analytics on the same server without sizing. Resources compete with recording, especially during transcoding and recognition.

If you need both stable recording and analytics, split roles in advance or at least test the target configuration under load.

Example calculation with no complex formulas

Consider a school or clinic: 48 IP cameras, some in corridors, some outdoors. Settings: 1080p, 15 FPS, H.265, 24/7 recording, 30-day retention. We need network and disk estimates.

Use an average bitrate per camera. For 1080p/15 FPS/H.265 a common assumption is 2–4 Mbps. Take 3 Mbps (outdoors may be higher due to foliage, snow and headlights).

Traffic: 48 × 3 = 144 Mbps. In megabytes that's 144 / 8 = 18 MB/s continuous recording.

Archive: 18 MB/s × 86,400 s ≈ 1.55 million MB per day ≈ 1.5 TB/day. For 30 days that's about 45 TB raw. Add 15–25% for overhead and bitrate variance and target roughly 55 TB usable capacity.

Now RAID. If you build RAID 6, you lose two disks' worth to parity. For example, 10 × 10 TB = 100 TB raw, about 80 TB usable (and slightly less after format). That gives good margin for 30 days.

What changes with growth:

• Add 16 cameras (64): 64 × 3 = 192 Mbps (24 MB/s), archive ≈ 60 TB for 30 days before margin.
• Raise FPS to 25: bitrate commonly increases ~1.5–1.8×. If cameras go to 5 Mbps then 48 × 5 = 240 Mbps and archive may reach ~75 TB for 30 days.

Before final selection verify inputs with security and IT: is 30-day retention required for all cameras or only some, is recording strictly 24/7 or event-based, will analytics and extra streams be used, how many concurrent views, and what are network uplinks (1G/10G)?

Pre-purchase checklist and next steps

Spend 20 minutes rechecking inputs before buying hardware. Most VMS issues start not from a weak server but from wrong expectations about bitrate, retention and peak loads.

What to verify before final quote:

• Capture real bitrate from several cameras day and night. Night, rain or snow often raise throughput 1.5–3×.
• Recalculate retention using usable capacity. RAID, formatting and reserves reduce available TB.
• Estimate network and disk write margin for peaks. Even with low average load simultaneous bitrate spikes can saturate a 1G link.
• Plan disk servicing: hot spare, SMART monitoring, degraded array procedures, replacement order and timing.
• Fix which VMS features will be enabled (analytics, server-side detection, transcoding). These directly affect CPU/GPU and RAM.

A useful quick test: simulate the worst case (night + motion) and verify that recording and network hold up even if averages look fine.

Then a simple rule: define VMS and camera requirements first, then server and disks, and only after that finalize cost. If you expect growth in 12–24 months include margin so adding cameras isn't an emergency upgrade.

If the project is in Kazakhstan and you need supply, deployment and ongoing support, consider both hardware and integration. For example, GSE.kz (gse.kz) as a manufacturer and systems integrator can provide rack S200 servers for archives and the infrastructure work, including 24/7 support across the country.