Search

The Redundancy tab shows a management server and a failover node monitored by a heartbeat. Health, latency, CPU and memory come from probes of each server's API, and video pipeline status is checked as well. A replication agent on the failover node periodically pulls a full export of database and configuration from the live server. Only files whose checksum changed cross the network. Users and sessions are mirrored into the standby's own database, so existing login tokens stay valid there and clients remain signed in after a takeover.

The Configuration tab sets how failure is detected and how the standby stays current. The monitor probes each server at the probe interval, and a server is declared failed only after the configured number of consecutive failed probes. Required services are always monitored, while optional ones such as VoIP or analytics only count if ticked. Backup interval, number of snapshots kept and a bandwidth cap control the replication agent on the failover node. Alerts can go out by e-mail (SMTP), Telegram or desktop notification.

During a backup cycle the failover node requests a manifest of the live server's files and databases, then fetches only what changed since the previous snapshot. Unchanged files are linked from the previous copy, which is why the panel can show thousands of files with only a handful fetched. Progress in files and megabytes is written to a status record that the client shows live. The finished export is rotated into a snapshot folder, and the standby's database line reads Syncing while data is being applied.

A takeover happens automatically when the failure threshold is reached, or manually with Force Takeover. The standby then serves the failed server's cameras, the failed server is marked offline, and the banner and top status line turn red. When the original server answers its probes again, Failback moves the cameras home. The Configuration tab can also do this automatically after the server has been healthy for a set number of minutes. Clients keep working because users and sessions were already mirrored to the standby.

The Event Log tab records each step of the redundancy process as it happens, with a local time stamp: a forced replication cycle, the takeover request, the start of the takeover worker, camera migration, the number of streams stopped on the failed server and the final result. The entries come from the server's takeover sequence and are kept for the session, with a Clear button. Because every transition is written in order, an operator can check afterwards what the system did and copy it into an incident report.