Introduction

ProxDR is disaster-recovery orchestration for Proxmox VE — the SRM/Zerto-class tooling Proxmox has always lacked. It replicates your VMs and containers to a second site, lets you test recovery without touching production, and performs orchestrated failover and failback when you need it. It runs on any storage backend, not just ZFS or Ceph.

ProxDR ships as a single Go binary that serves both the daemon and the web UI. There are no agents to install inside your guests and nothing to bolt onto the Proxmox hosts themselves.

Core concepts

A few terms show up throughout these docs and the UI:

• Site — one ProxDR controller and the Proxmox cluster(s) it manages. Each install is one site, with its own identity (a name and a UUID).
• DR Site Pair — one production site paired with one recovery site. This is the unit ProxDR licenses and the unit you fail over. A pair can protect any number of nodes or guests.
• Protected guest — a VM or container you’ve enrolled for replication on a pair. ProxDR captures near-continuous recovery points for it.
• Controller — the ProxDR instance (the daemon + its local database of pairs, guests, and settings). It never sits in the data path of a running guest, so a controller outage never takes down your workloads.

How a recovery works, end to end

1. Connect your Proxmox nodes to a ProxDR controller (Inventory).
2. Pair your production controller with a recovery-site controller (Site Pairs).
3. Protect the guests you care about; ProxDR replicates them continuously.
4. Test recovery in an isolated network whenever you like — no disruption.
5. Fail over with a recovery plan when a real disaster hits, then fail back to the original site once it’s healthy.

The rest of these docs walk that path: install, first run, then connecting nodes and creating a pair.