NVR vs VMS for government, campus and city surveillance

What is the difference between an NVR and a VMS?

An NVR is a single appliance that records, stores and plays back video from IP (Internet Protocol) cameras, while a VMS is software that runs on servers and manages recording, live viewing, playback, users and events across many recorders and sites. The NVR is a box with a fixed number of camera channels and its own disks. The VMS is a platform that grows by adding servers, storage and licences.

Both sit in the same place in a surveillance system. In its advisory of 11 March 2024, MeitY (the Ministry of Electronics and Information Technology) listed the key components of a video surveillance system as cameras, VMS software, storage in NVRs or digital video recorders (DVRs), and power supply. A DVR does the NVR's job for analogue cameras on coaxial cable. An NVR takes IP cameras over the network.

The line between the two has blurred. Many NVRs now have a web client and a mobile app, and some VMS products are sold pre-installed on a server as an appliance. The useful question for a buyer is about architecture, not hardware: one self-contained recorder per site, or one central platform that manages many recording servers as a single system.

How do an NVR and a VMS compare side by side?

An NVR is simpler and cheaper to start with, and a VMS is easier to grow, protect against failure and integrate. The table sets out the differences that usually decide the choice in public projects.

In the table, SAN means a storage area network and NAS means network-attached storage. An API is an application programming interface and an SDK is a software development kit, the two ways a vendor usually lets other systems connect to its product. OS means operating system.

How far can each one scale?

An NVR scales by adding more boxes, and a VMS scales by adding capacity to one system. That difference sounds small until a site has several recorders.

Each NVR has limits on camera channels, incoming bitrate and disk bays. When a site outgrows one, the second NVR is a second system, with its own user accounts, its own search and its own health alerts. Operators have to know which box holds which camera, and an investigation that spans two buildings means searching two recorders.

With a VMS, recording servers are added behind one management layer. Operators search every camera from one client. Administrators create users and roles once. Health monitoring covers every server and camera in one view. This is why city and campus systems, which are usually built in phases and extended by different departments, tend to be built on a VMS.

Sizing a VMS depends on the total bitrate coming in, not only the camera count. Bitrate depends on resolution, codec (for example H.264 or H.265), frame rate and how busy the scene is. A bid should show the sizing calculation, the headroom left for growth, and what is added when the headroom runs out.

What happens when a recorder or server fails?

When an NVR fails, its cameras usually stop recording until it is repaired or replaced, while a VMS can be designed so that a standby server takes over. For public surveillance, where video may be needed as evidence, that gap is often the deciding factor.

RAID (a redundant array of independent disks) inside an NVR protects against a failed disk. It does not protect against a failed power supply, motherboard or software fault in the box itself. Some NVR ranges support a standby unit that takes over, but this is model-specific and has to be checked, not assumed.

A VMS can be designed with failover at each layer. Spare recording servers take over cameras from a failed one. The management server can be duplicated or clustered. Servers can run as virtual machines on hosts built for high availability. Edge recording adds another layer: ONVIF, the open industry forum for IP security products, publishes Profile G for edge storage and retrieval, under which a camera can record on the device itself and a conformant VMS can configure and control that recording. A camera recording to its own memory card keeps video through a short network or server outage.

• Specify the longest recording gap the owner can accept, and design failover to meet it
• Require an alert when any camera stops recording, not only when a disk fails
• Put the recorders, and the network switches that power cameras over Power over Ethernet (PoE), on UPS (uninterruptible power supply)
• Test failover at commissioning by switching off a recording server and checking what was recorded

How does each one connect to an ICCC?

An ICCC connects to a VMS through one integration, while a fleet of NVRs usually needs a connector for each recorder make and model. The ICCC needs live video, recorded playback, alarms and analytics events, and camera health. A VMS exposes all of these through one API or SDK.

With separate NVRs, the integrator has to write and test a connector for each recorder type, and repeat the test when firmware changes. Recorders from different makers expose different features, so the operator experience on the video wall becomes uneven.

ONVIF profiles standardise how cameras talk to recorders and VMS software. The link from the VMS up to the ICCC is usually the VMS vendor's own API or SDK. A tender should therefore ask for that interface to be documented and licensed for the ICCC's use, and should state which events the ICCC must receive.

Which one fits a government office, a campus or a city?

An NVR fits a single building with a fixed camera count, and a VMS fits anything with several buildings, several operator groups or a command centre.

• Single government office or building: an NVR with one guard room is usually enough, provided recording failure raises an alarm and the NVR sits on UPS
• Campus, such as a university or hospital: a VMS with recording servers in the data centre or in each building, so one control room can see every camera and security staff share one search
• City: a VMS with central and distributed recording, role-based access for police, traffic and municipal users, and an integration into the ICCC
• Remote or poorly connected sites in a larger system: local recording at the site, on an NVR or on camera edge storage, managed from the central VMS

What should a tender specify for recording and video management?

A tender should specify outcomes, such as retention, failover and integration, rather than naming an NVR or a VMS as a product type. Security of the cameras themselves is a separate requirement in India, covered by MeitY's Essential Requirements for security of CCTV. MeitY's advisory of 11 March 2024 also asks government buyers to isolate CCTV networks, change default passwords, keep firmware current and restrict remote access.

• Retention in days for each camera group, at a stated resolution and frame rate
• Maximum acceptable recording gap, and the failover design that achieves it
• Central user management with roles and an audit log of who viewed or exported video
• A documented API or SDK from the VMS to the ICCC, with the list of events to be passed
• ONVIF profile conformance for cameras and for the VMS, checked against the ONVIF conformant products list
• Storage sizing calculation with growth headroom, submitted with the bid
• Patch and firmware update responsibility for the full maintenance period

How Ahuva approaches surveillance recording and VMS

Ahuva's video surveillance scope covers IP surveillance, AI/ML (artificial intelligence and machine learning) analytics, automatic number plate recognition (ANPR) and centralised VMS, alongside city traffic surveillance, adaptive signal control and enforcement. Its ICCC scope includes integrating CCTV (closed-circuit television), GIS (geographic information system) maps, IoT (Internet of Things) sensors, SCADA (supervisory control and data acquisition) and analytics, with incident management. It is currently delivering Project Sarthi for the Greater Visakhapatnam Municipal Corporation via KELTRON, whose published scope includes violation enforcement at 90 junctions, facial recognition at 12 sites and one integrated command and control centre. Its OEM (original equipment manufacturer) authorisations include Bosch for surveillance, public address and life-safety systems, and CP Plus for surveillance hardware.