Site Pairs

The Site Pairs page manages the links between this controller and its peer recovery sites. Each pair is one production site ↔ one recovery site.

Creating and joining

• Create a pair on one side to generate a pairing code and reveal this site’s fingerprint.
• Join on the other side with that code and the peer’s address.

The two controllers pin each other’s fingerprints and bring up a mutually authenticated link. See Create a DR Site Pair for the full handshake and internet/tunnel guidance.

What a pair shows

For each pair you can see its role (primary/recovery), the peer’s name and reachability, the guests protected over it, and its current DR state (protected, testing, failed over, etc.).

Peer console link

If the peer advertised its web console URL, ProxDR shows an open peer console link so you can jump to the other site’s UI in a click.

Driving DR from either site

Both sites run the identical web UI — same pages, same buttons. You can drive every pair operation (failover, DR test, recovery points, re-IP, planned migration, protect/unprotect, failback) from whichever controller you can reach, so you’re never locked out of recovery.

Behind the scenes each action is carried out by the one controller that owns it — recovery-side actions (failover, DR test, points) run on the recovery; source-side actions (protect, sync) run on the primary — routed automatically over the pair’s authenticated link. Because every request funnels to that single owner, two operators (or both sites) can’t drive the same guest into a split-brain: a second attempt simply joins the operation already running. Each operation’s log names which controller actually ran it (e.g. “running on proxdr-arc (recovery)”), so it’s always clear where work happened.

A guest’s detail screen is the same on both sites — the same health, configuration, live metrics, run history, and operations — with each section talking to the correct controller.

Disaster mode — when the primary is gone

The whole point of DR is that the primary can be down. When it is, the recovery site stays fully operable on its own: pages render immediately instead of hanging on the unreachable peer, and failover, site-wide failover, DR tests, and recovery points all work locally. Source-owned actions (protect, sync) show a clear “source unreachable” state instead of spinning. Declaring a disaster offers a force failover that promotes the recovery copy without waiting on the dead primary — and when the primary comes back, ProxDR reconciles cleanly, without double-fencing the guest.

Removing a pair

Deleting a pair unpairs both sides and stops replication over it. Guests protected only on that pair are no longer replicated.

Next: Replication — protect guests and drive recovery.