Single-Site vs Geographic Redundancy for SCADA
A redundant server pair in one rack survives a dead server. It does not survive the room flooding, the site losing power, or a fire in the building. This page compares keeping redundancy inside a single site against spreading it across two geographically separate locations, so you can decide whether a second site is protecting against a credible event or against one so rare it is cheaper to accept.
Single site vs geographic redundancy in one line: Single-site redundancy puts both servers in one location and survives node failure but not a site-level loss such as fire, flood, or utility power failure. Geographic redundancy places a standby at a second location and survives losing the whole primary site, at the cost of a WAN replication link and higher latency. Choose a second site when losing the primary location is a credible event you cannot tolerate, not by default.
Separate Node Failure From Site Failure
The two designs protect against different classes of event, and conflating them is the root of most bad decisions here. A single-site redundant pair, the pattern in a redundant server pair for SCADA, protects against one server dying. Both machines share the room, the power feed, the network drop, and the roof, so any event that takes out that shared context takes out both nodes at once. Node redundancy is real protection against node failure and no protection at all against site failure.
Geographic redundancy, described in the explainer on geographic redundancy for SCADA, places a standby server or full system at a physically separate location so that the loss of the primary site, whether from fire, flood, extended power loss, or a network cut, does not end supervisory operation. The trade is that the two sites must be linked over a wide-area network, which adds latency, a recurring cost, and its own failure mode: the very link between the sites can drop while both remain healthy, which reintroduces the split-brain problem across a much longer wire.
Compare the Two Redundancy Scopes
The table separates what each scope actually buys, because a project that has paid for node redundancy often mistakenly believes it has paid for disaster recovery.
| Factor | Single-site redundancy | Geographic redundancy |
|---|---|---|
| Survives one server failing | Yes | Yes |
| Survives site power loss | No | Yes |
| Survives fire or flood at the site | No | Yes |
| Link between nodes | Local network - fast | WAN - slower, recurring cost |
| Replication | Local, low latency | Over distance, must plan for lag |
| New failure mode | Local link loss | WAN partition and cross-site split-brain |
| Right when | Site loss is not a design concern | Losing the primary site is credible and intolerable |
Geographic redundancy also forces a data-consistency decision the single-site design mostly avoids. Synchronous replication across a WAN slows every write to the round-trip time of the link, while asynchronous replication is fast but risks losing the last few seconds of data if the primary dies before the standby catches up. Neither is wrong; the choice depends on whether a small data gap at the moment of disaster is acceptable for your recording duty.
The failover itself is harder across sites. A cross-site cutover often involves redirecting clients, re-establishing field communications from the second location, and confirming the standby has current data, so the failover drill for a geographic design is a bigger exercise than a rack-local switch and must be practiced for real, including the WAN-down case.
When Each Scope Is Justified
Single-site redundancy is the right scope when a site-level loss is not part of your threat model or is covered another way. Many plants accept that a catastrophic site event means an orderly shutdown rather than continued remote operation, and for them paying for a second control center protects against an event whose correct response is to stop, not to keep running. If a fire in the control room means the plant is evacuating anyway, remote supervisory continuity buys little.
Geographic redundancy is justified when continued operation through the loss of the primary site is genuinely required. Pipeline control rooms with a regulatory duty to maintain supervision, operations that span regions and cannot pause, and any system where the primary location is itself exposed to a credible regional hazard all belong here. The second site is protecting a specific, statable requirement to keep watching and controlling even after the first location is gone.
There is a lighter intermediate posture worth naming: a single active site plus off-site backups and a documented rebuild plan. This is not geographic redundancy, because recovery takes hours rather than seconds, but it protects the data against site loss without a full second control center. For sites that must not lose the history but can tolerate a rebuild outage, off-site backup is the honest and far cheaper answer.
Pitfalls in Geographic Design
The signature pitfall is believing node redundancy is disaster recovery. A beautifully engineered redundant pair in one room gives an organization false confidence that it is protected against a flood or fire that will take both servers together. State plainly which events your redundancy actually survives, and if site loss is in scope, the redundancy must cross sites or the data must at least live off-site.
A second trap is ignoring the WAN as a failure mode. The link between two sites is slower and less reliable than a rack cable, and when it partitions, both sites can be healthy yet unable to coordinate, producing cross-site split-brain unless a quorum witness sits at a third location to arbitrate. The final pitfall is choosing synchronous replication without accounting for its latency cost, so every write waits on the WAN and the system feels sluggish, or choosing asynchronous without accepting that a disaster can cost you the last few seconds of unreplicated data.
Frequently Asked Questions
Does a redundant server pair protect against a site disaster?
No. A redundant pair in one location survives a single server failing but shares the room, power, and building with its partner, so a fire, flood, or extended power loss takes both servers together. Surviving the loss of the whole site requires geographic redundancy across two locations, or at minimum off-site backups with a rebuild plan. Node redundancy and disaster recovery are different protections that solve different problems.
What does geographic redundancy add over a single site?
It places a standby system at a physically separate location so the loss of the primary site does not end supervisory operation. That survives fire, flood, and utility failure at one location, at the cost of a WAN link with higher latency and recurring expense, a replication-consistency decision, and a harder failover that redirects clients and field communications to the second site. It is justified when continued operation through a site loss is a real requirement.
Is off-site backup a cheaper alternative to a second site?
For many operations, yes. Off-site backups plus a documented rebuild plan protect the historian and configuration against a site loss without funding a full second control center. Recovery takes hours rather than seconds, so it is not geographic redundancy, but it prevents permanent data loss. Choose it when you must not lose the history but can tolerate a rebuild outage after a disaster rather than needing seamless cutover.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.