Why redundant SCADA servers aren't automatically interchangeable backup strategies — "we have a backup" is not one fact, it's a spectrum.
Ask whether a SCADA system has a redundant server and the answer is usually just "yes." That single word hides one of the most consequential design decisions in the whole architecture: is that backup server fully powered on, continuously synchronized, and ready to take over in a heartbeat — or is it sitting idle, waiting to be started up and brought current only after something has already gone wrong? Those are two fundamentally different promises, and mistaking one for the other is exactly how a "protected" system turns out to have a real, unplanned gap in coverage the day it actually needed to fail over.
A hot standby server is fully powered on and actively running alongside the primary at all times, continuously receiving the same live data and system state through real-time (or near-real-time) mirroring. If the primary fails, the hot standby is already caught up — it can take over, often automatically via a failover mechanism, in seconds, with essentially no loss of current operational data. A cold standby server is not actively running or synchronized during normal operation — it may be powered off entirely, or simply not receiving live updates. If the primary fails, someone has to start it, configure it, and bring it current with the most recent available data before it can take over — a process that takes real, meaningfully longer time, and whose starting point may already be somewhat stale relative to the instant the primary went down.
Hot standby buys near-instant, low-disruption failover — at the ongoing cost of running duplicate hardware continuously and paying the bandwidth/processing overhead of keeping it synchronized every moment the primary is up. Cold standby buys a much lower ongoing cost — at the price of a real, meaningfully longer recovery window and a starting data set that's only as current as its last update, not the instant the primary actually failed. Neither is universally "better." A critical continuous process — one where even a brief operational gap or a few minutes of stale data would be genuinely consequential — needs the near-instant, always-current guarantee that only hot standby provides. A less time-critical backup, where a recovery delay measured in minutes or hours is truly tolerable, gets the same protection it actually needs from cold standby at a fraction of the ongoing cost. The design question isn't "do we have a backup" — it's "how much of a gap can this specific system survive, and does the backup we've built actually close that gap?"
Not really. "Redundant server" describes hardware topology, not the level of operational continuity that hardware actually delivers when the primary goes down. A hot standby — continuously running, continuously synchronized, capable of automatic near-instant failover — and a cold standby — powered off or unsynchronized, requiring a manual startup and catch-up process that takes real time and may start from somewhat stale data — provide genuinely different levels of protection, even though both are legitimately "redundant." The mistake shows up when a system that actually needs hot-standby-level continuity — critical continuous process control, safety-related monitoring, anything where even a brief gap is unacceptable — is protected by a cold standby instead, because someone assumed "there's a backup" already answered the question. It doesn't. The manual recovery process a cold standby requires is a real, potentially serious operational gapin exactly the scenario a properly matched hot standby design would have closed. The right choice depends on the actual criticality and acceptable recovery-time tolerance of the specific system being protected — not on whether the word "redundant" appears in the architecture diagram.
Explains the two fundamentally different ways a redundant SCADA server can back up a primary system — hot standby, which stays fully powered on and continuously synchronized so it can fail over automatically in seconds, and cold standby, which sits idle or unsynchronized and requires a manual startup, configuration, and data catch-up process before it can take over — and why matching the wrong strategy to a given system's actual criticality is a real, consequential design mistake, not a minor implementation detail.
A hot standby server runs in parallel with the primary at all times, continuously receiving the same live data and system state through real-time or near-real-time mirroring. Because it is always caught up, a failover mechanism — often fully automatic — can switch operation to the standby within seconds of the primary failing, with essentially no loss of current operational data. That guarantee has a real, ongoing cost: the standby hardware has to run continuously whether or not it is ever called on, and keeping it synchronized consumes bandwidth and processing on an ongoing basis, not just at the moment of failure.
A cold standby server is not actively running or synchronized during normal operation — it may be powered off entirely, or simply excluded from live data updates. When the primary fails, the standby has to be started, configured, and brought current with the most recently available data before it can take over, and that recovery process takes meaningfully longer than a hot standby's near-instant failover. It also means the standby's starting data set reflects conditions as of its last update, not the exact instant the primary went down — a real data-currency gap, not just a time delay. In exchange, cold standby avoids the cost of continuously running duplicate hardware and continuous synchronization, making it substantially cheaper to maintain.
Choosing between hot and cold standby is a real engineering tradeoff between ongoing cost and recovery speed/data currency — and getting the match wrong is a genuine, consequential design error, not a paperwork detail. A critical continuous process — where even a brief operational gap or a window of stale data would be operationally or safety significant — needs the near-instant, always-current protection that only hot standby provides; a cold standby protecting that same system would leave a real gap during its manual recovery window exactly when the system could least afford it. Conversely, a less time-critical backup role, where a recovery delay of minutes to hours is genuinely tolerable, gets the protection it actually needs from cold standby at a fraction of the ongoing cost — paying for continuous hot-standby synchronization there would be spending real money to solve a problem the system doesn't have. "Having a backup" is not one fact with one meaning; it only means as much as the failover time and data-currency guarantee actually behind it.
Not automatically. Hot standby buys near-instant, low-disruption failover, but it comes with a real ongoing cost: duplicate hardware running continuously and continuous synchronization overhead, whether or not a failure ever occurs. For systems where a recovery delay of minutes to hours is genuinely tolerable, that ongoing cost buys protection the system doesn't actually need. The right choice depends on the specific system's tolerance for an operational gap, not simply on what's affordable.
It means the standby continuously receives the same live process data, alarm states, historian updates, and control context as the primary — through mechanisms like database replication, shared/mirrored storage, or a dedicated synchronization link — so that at any given instant its internal state closely matches the primary's. This is what allows failover to happen with minimal to no loss of current operational data.
Because a cold standby only receives data at whatever interval it's updated on — for example, a periodic backup or scheduled data pull — rather than continuously. If the primary fails between two of those updates, the cold standby's most recent data reflects conditions as of the last update, not the instant of failure, so some amount of recent operational history and current state is genuinely unavailable to it until manual reconciliation.
Yes, and many real deployments do exactly this deliberately — hot standby for the SCADA server itself or other components where near-instant failover is critical, combined with cold standby (or simple periodic backups) for less time-critical supporting systems, such as reporting servers or historian archives, where a longer recovery window is acceptable. Matching the strategy component-by-component to actual criticality, rather than applying one redundancy approach uniformly, is usually the more cost-effective design.
Often the automatic failover mechanism handles the technical switchover, but most well-run sites still document and periodically test a manual failover procedure as a fallback — because the automatic mechanism itself is a piece of software that can fail or misbehave. Hot standby dramatically reduces reliance on manual intervention under normal failure conditions, but rigorous designs don't treat automatic failover as something that can never itself need a human to step in.
Try our SCADA Studio
More calculators, simulators, and guides for this discipline.