Secondary SCADA server: what must be identical, and how fast does it take over?

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • SignalFlow
    Junior Member
    • 21.10.2026
    • 7

    #1

    Secondary SCADA server: what must be identical, and how fast does it take over?

    Our water pumping station runs on a single Omnivex SCADA server. After a disk failure last month we had no monitoring for six hours, so management approved a second PC for redundancy.
    I found Redundancy under the Tools tab. Before I start, I'd like to understand the requirements. Do both PCs need their own database? Do I have to copy the project manually every time I change a screen? And what value should I use for the time the secondary waits before taking over? I don't want it to take over during a short network glitch.
  • Technical Support
    Senior Member
    • 11.08.2025
    • 105

    #2
    Good decision, and good questions to settle before you install.
    Requirements
    - Both servers must run the same software version.
    - Both servers must have identical project files.
    - Both servers must have access to the same project database. So the answer to your first question is no: not two separate databases, but one database both servers can reach. Place the database so that it isn't on the same single disk you're trying to protect against.
    Setup
    On the primary: Tools > Redundancy, select the primary role, enter the Port used for communication between the servers, and confirm.
    On the secondary: Tools > Redundancy, select the secondary role, enter the same Port, the primary's IP address, and the waiting time before takeover, then confirm.
    The secondary continuously monitors the primary and takes over automatically if the primary stays inactive for the configured time. Failover events appear as notifications on the main server pages.
    Project changes
    Since the project files must be identical, include "copy project to secondary" in your change procedure. Using Import/Export Project from the File tab is one way to keep them aligned. A mismatch is the most common reason a failover looks "wrong".
    Choosing the timeout
    There's no single correct value. Measure how long your typical network interruptions last (switch restarts, for example) and choose a timeout comfortably above that. Too short gives unnecessary takeovers, too long extends the gap in monitoring.
    Test it
    Plan a test: stop the primary during a quiet period, confirm the secondary takes over and the notifications appear, then write down how you return to normal operation.
    Documentation: https://greensoft.ai/documentation/o...da/redundancy/

    Comment

    Working...