Most SCADA redundancy schemes are built out of one repeating unit: two servers configured as a pair, one acting as primary and one as backup. Understanding that building block - how the two nodes are wired together, how they decide who is in charge, and how the pair behaves when part of it fails - is the foundation for everything from a single redundant control room to a multi-site design. This guide stays at the SCADA server and software layer and explains the redundant server pair as a unit in its own right.
Redundant Server Pair in one line: A redundant server pair is two SCADA servers configured to work together as a primary and a backup, joined by a dedicated synchronization and heartbeat link. One node is assigned the primary role and does the live work while the other tracks its state and monitors its health, ready to take over if the primary fails. The pair is the basic two-node building block from which larger redundant architectures are assembled.
A redundant server pair is two physically separate machines running the same SCADA software with the same project, deliberately connected so they can act as one logical system. Each server has its normal network path to the field devices and to the operator clients, so either one can do the full job. What makes them a pair is an additional, usually dedicated link between them - often a separate network interface on each server wired directly to the other or through a private switch - reserved for keeping the two nodes coordinated. Keeping that traffic off the general network protects it from congestion and keeps the two servers talking even when the wider network is busy or degraded.
On the configuration side, both servers are told they belong to a redundant pair and given the identity of their partner. The project is deployed identically to both so their view of the process is the same. Operator clients and, where possible, field-facing connections are set up to reach whichever server currently holds the primary role, so that when the role moves from one node to the other, clients and devices follow the primary rather than staying stuck on a dead server. The aim of all of this is that the pair presents a single, continuous system to operators even though it is really two machines taking turns.
The dedicated link between the two nodes carries two related jobs. The first is synchronization: the primary streams its live state - tag values, alarm status, trend data - to the backup so the backup stays current. The second is the heartbeat, a continuous signal each node uses to confirm the other is alive. As long as the backup hears the primary's heartbeat and receives its state, it stays passive. When the heartbeat stops and health checks agree the primary is truly gone, the backup concludes it must take over, promotes itself to primary, and begins doing the live work.
Role assignment - deciding which node is primary - can be handled a few ways. Often one server is designated the preferred primary and takes that role whenever both are healthy, with the other defaulting to backup. After a failover, the recovered node typically returns as backup rather than automatically reclaiming primary, to avoid a second disruption. The important principle is that at any moment exactly one node must hold the primary role. A well-designed pair enforces this so that two servers never both believe they are primary and start issuing conflicting commands to the field - the split-brain condition that redundant designs work hard to prevent.
Looking at the pair as a whole, three failure patterns matter. The cleanest is a single-server failure: the primary dies, the backup detects it and takes over, and the system runs on one node until the failed server is restored. This is the case redundancy exists for, and it should be nearly transparent to operators. The second is failure of the synchronization and heartbeat link while both servers stay alive. Now each node can lose sight of the other, and unless the design has a tiebreaker, both may decide the partner is dead and try to become primary - a split-brain. Defenses such as a quorum witness or redundant heartbeat paths exist precisely to handle this mode.
The third pattern is a shared dependency that takes out both nodes at once, which defeats the pair entirely. If the two servers share the same power feed, the same rack, the same network switch, or the same room, then a single event there can down both. That is why a redundant server pair is only as strong as the independence of its two nodes, and why serious designs separate power, network paths, and physical location. In cloud SCADA the same pairing logic applies but is handled by the platform: redundant instances are spread across independent infrastructure so no single fault takes down both, and Merobix presents the resulting pair as one continuous system without the customer wiring or maintaining the two servers themselves.
Usually one server is designated the preferred primary and holds that role whenever both nodes are healthy, while the other stays as backup. If the primary fails, the backup promotes itself. The overriding rule is that exactly one node holds the primary role at any time, and the pair is configured to enforce that so the two servers never both act as primary at once.
It carries two things: the live state the primary streams to the backup so the backup stays current, and the heartbeat each node uses to confirm the other is alive. It is usually a dedicated connection kept off the general network so that congestion elsewhere does not disrupt coordination. If this link fails while both servers stay up, the pair risks a split-brain, which is why designs add tiebreakers and redundant heartbeat paths.
No. A redundant server pair operates at the SCADA server and software layer - the supervisory system that gathers, historizes, alarms on, and displays data. Controller redundancy is at the PLC or control layer on the plant floor, protecting the logic that runs the process. A facility can and often does have both, since they protect different tiers of the system.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.