🚧 In development — ProxDR is coming soon. You're viewing an early preview.

ProxDR
📚 Browse docs

Recovery placement & networking

When you fail over, ProxDR needs to know where recovered guests should run and how they should be networked at the recovery site.

Recovery node

Pick the node in the recovery cluster where failover and DR-test VMs are placed. If you don’t set one, ProxDR uses the first SSH-configured remote’s host by default. Set a pair-wide default in Settings or when configuring the pair, and override it per guest on the Replication page when a particular workload needs to land on a specific recovery node — the setting applies across the pair from either site.

Where replicas are stored

Independently of where guests run on failover, you choose where each guest’s recovery replica physically lives at the recovery site — any directory/NFS/CIFS share or a native ZFS/LVM-thin volume, per guest or per pair. See Where the replica lives and the Shadows page.

Network mapping

Production and recovery sites rarely share the same bridges or subnets. Network mapping (on a pair) tells ProxDR which recovery-side bridge each production network maps to, so guests come up attached to the right network.

Keeping IPs — the DR edge gateway

For workloads that must keep their addresses, ProxDR can run a DR edge gateway: the recovery node routes an isolated bridge that mirrors a production subnet, so recovered VMs boot with their original IPs and the gateway handles NAT and port-forwarding. This also underpins isolated DR testing, where test VMs run on a fenced network that can’t reach production.

Re-IP profiles

Alternatively, apply a re-IP profile to rewrite guest addresses on failover (new IP, gateway, DNS) — useful when the recovery site uses a different address space and you don’t need to preserve IPs.

You configure these per pair on the Site Pairs and Replication pages. Next: protect your guests.