Record every required stream—and retrieve the right evidence when it matters
Surveillance storage is a sustained-write system with strict retention and retrieval expectations. Camera count is only the beginning: bitrate, recording mode, metadata, playback, failover and archive determine the architecture.
STREAMS
METADATA
The VMS remains responsible for recording format, indexing, retention and supported storage access.
Plan for recording, investigation and failure at the same time
A platform that handles normal recording can still fall behind when review, export, archive and recovery traffic overlap.
Sustain many sequential streams
- Aggregate all configured camera, audio and metadata bitrates.
- Include container, index and filesystem overhead.
- Preserve headroom for short bitrate peaks and busy scenes.
Model bursts, not only averages
- Motion and analytics reduce average volume but can activate many cameras together.
- Pre-event and post-event buffers add data around each trigger.
- Worst-case events should not exhaust capacity or throughput.
Retrieve while recording continues
- Multiple operators may review different time ranges simultaneously.
- Timeline scrubbing and thumbnails introduce small, less sequential reads.
- Evidence export consumes both read bandwidth and destination capacity.
Keep ingestion protected under stress
- A failed disk, path, controller or node must not silently shorten retention.
- Rebuild and rebalancing compete with foreground recording.
- Measure the acceptable recording and playback rate during failure.
Estimate from bitrate, cameras, recording time and retention
The basic volume calculation is simple; production sizing adds overhead, free space, protection, rebuild headroom and growth.
Do not size from resolution alone: two cameras with the same resolution can produce very different volumes because codec, frame rate, compression, motion and scene complexity affect bitrate.
Let the VMS support matrix determine the data path
Recording software may require local block devices, support network shares for recording or archive, or expose an application-specific object-storage workflow.
| Access method | Often fits | Potential advantage | Validate with the VMS |
|---|---|---|---|
| Local storage | Recording server with internal media | Simple I/O path and local bandwidth | Server failure, capacity growth, replacement and evidence recovery |
| SMB / NAS | VMS-supported network recording or archive paths | Central capacity and familiar file management | Exact VMS support, service identity, permissions, locking and failover behaviour |
| NFS | Linux-oriented VMS, analytics or archive workflows | Established shared file access | Application support, mount behaviour, permissions and reconnect semantics |
| iSCSI | Block volumes presented to individual recording servers | Broad host support over Ethernet | Volume ownership, multipathing, queue design and filesystem limits |
| Fibre Channel | Qualified SAN-based recording environments | Dedicated mature fabric and predictable operations | HBAs, zoning, multipathing and VMS/OS qualification |
| NVMe-oF | Qualified high-throughput or latency-sensitive block volumes | Efficient remote NVMe access over TCP or RDMA | Host support, multipathing and whether the VMS benefits from the path |
| S3-compatible object | VMS-integrated archive, cloud or object-recording workflows | API access and scalable retention tiers | Native application integration; S3 is not automatically a mounted recording volume |
No compatibility claim is implied: euroNAS supplies storage interfaces; the VMS vendor or system integrator must validate the exact software version, operating system, protocol and failover design.
A recording path must have one clear owner
VMS writes to a file share
The storage service owns the shared namespace. This can simplify central capacity when the VMS explicitly supports network file storage and its permissions and reconnect behaviour are configured correctly.
VMS writes to a block volume
The host owns the filesystem. Presenting the same ordinary filesystem to several recording servers is unsafe unless the VMS or a cluster-aware filesystem coordinates concurrent access.
Keep recent footage fast and older footage economical
A tiered design can separate the active recording database from searchable archive and independent evidence retention—when the VMS supports those transitions.
Protect continuous ingest
Optimise for sustained writes, current indexes and simultaneous operator playback. Reserve performance and free-space headroom.
Balance capacity and retrieval
Older footage may move to capacity-oriented file or object storage while remaining available through the VMS catalogue.
Separate case retention
Exported evidence may require independent access control, integrity verification, retention policy and documented chain of custody.
Archive is application-controlled: copying raw recording files outside the VMS may not preserve indexes, metadata or a supported recovery path. Test a complete retrieval and export workflow.
Protect footage without confusing failover with evidence retention
Least privilege
Allow recording services—not ordinary users—to write the repository. Separate administration, viewing and export permissions.
Availability
Redundant paths, automatic failover or distributed services keep recording available after infrastructure faults.
Recovery points
Snapshots and replication address selected storage failures or accidental changes according to their schedule and isolation.
Evidence integrity
Encryption, signing, immutability and chain-of-custody controls depend on the VMS and the required regulatory process.
Surveillance data is sensitive personal data in many jurisdictions: retention periods, access logging, deletion and disclosure must follow the organisation’s legal and privacy requirements. Storage design does not replace that governance.
Use euroNAS platforms as implementation examples
The appropriate model depends on VMS support, number of recording servers, sustained load, retention, failure boundaries and operational ownership.
Focused recording repository
A dedicated storage server for a defined surveillance environment using a VMS-supported file or block path. It can also be deployed as a Virtual Storage Appliance.
- SMB, NFS, iSCSI, Fibre Channel or NVMe-oF according to VMS support
- Snapshots and replication options for the storage design
- Availability of the individual server must be addressed separately
Two-node recording availability
A local two-node design for a supported file or block recording path requiring automatic storage failover, using a synchronous Mirror or dual controllers with shared storage.
- Synchronous local continuity for the configured service model
- Separate asynchronous replication for additional recovery points
- VMS reconnect and recording-server failover must be tested end to end
Scale-out retention platform
A distributed Ceph platform exposing file, block and S3 services for supported recording or archive workflows where capacity and service endpoints must scale.
- Distributed data protection across defined failure domains
- Graphical cluster, drive, protection and service management
- No Ceph command-line knowledge required for routine operation
Virtualised VMS services
eEVOS can host qualified VMS servers and use internal, external shared or Ceph storage. Camera count, GPU or analytics requirements and VMS support must be validated.
- VM high availability and live migration
- Integrated Backup & Disaster Recovery for protected virtual machines
- Instant Backup & Recovery for protected virtual workloads
Questions that reveal the real recording requirement
How many cameras, codecs, frame rates, audio tracks and analytics metadata streams are recorded?
Is recording continuous, scheduled, event-driven—or a mix with pre-event and post-event buffers?
Which footage must remain searchable, for how long, and what happens when capacity is exhausted?
Which exact VMS version, operating system and file, block or object paths are supported?
What recording and playback rate must remain during a disk, link, controller or node failure?
Which access, encryption, export, integrity and chain-of-custody controls are required?
Validate the complete recording chain
Use current camera and VMS documentation for sizing, supported storage paths, retention and security.
Axis: Camera Station guidance
Official guidance relating average bitrate, maximum storage and retention, including the limits of capacity estimates.
Open Axis documentation →Milestone: recording storage
Official VMS guidance describing recording databases, NAS paths, retention and archive stages.
Open Milestone documentation →ONVIF: recording and storage
Industry specifications covering recording control, audio, video, metadata and network video storage models.
Open ONVIF Profile G →Bring the stream profile, retention target and VMS support matrix
We can review sustained recording load, playback concurrency, storage access, failure behaviour, archive and capacity growth for a business surveillance environment.