Replication & recovery operations

The Replication page is the heart of ProxDR: enroll guests for protection, watch their recovery objective, and run every recovery operation.

Protect a guest

Under Protect VMs, pick guests from a pair’s source side and enroll them. For each you can set a target RPO (recovery point objective) — how far behind the recovery copy is allowed to fall, from ~1 minute up. ProxDR replicates continuously toward that target on any storage backend.

Replication is storage-agnostic: whether your guests live on ZFS, Ceph, LVM-thin, or a directory, the same protection model applies. Open a guest’s detail page for its per-VM replication history, health, and settings.

Where the replica lives

Each protected guest’s recovery copy — its shadow — can be placed on any storage at the recovery site: a directory, NFS or CIFS share, or a native ZFS or LVM-thin volume. Set a default for the whole pair, or override it per guest, so replicas land where you have capacity instead of on the node’s root filesystem. On block pools (ZFS/LVM-thin), recovery points are captured as native snapshots.

See every replica across your sites — and reclaim orphaned ones — on the Shadows page.

Replication mode. By default ProxDR uses its universal dirty-bitmap engine on every backend. For ZFS-to-ZFS pairs, an optional native ZFS send/receive mode is available as an experimental feature (enable it in Settings).

Watch the initial sync

A guest’s first sync is a full seed and can take a while over the wire. The Replication page shows it live — a progress bar with percent, transfer rate, and ETA — sized to the guest’s actual allocated data, not its (often much larger) provisioned size. Every sync after that ships only changed blocks and is near-instant.

The guest keeps running normally throughout — its console and Proxmox tooling stay reachable even during that first full seed, so replication never locks you out of a VM.

Recovery points & point-in-time recovery

ProxDR keeps multiple retained recovery points, not just the latest — so you can roll back to a known-good moment. Points are integrity-checked at capture, and with the QEMU guest agent they can be application-consistent. Retention is configurable (hourly / daily / weekly).

Continuous integrity scrubbing

A recovery point that passes at capture can still rot later — a flipped bit on disk, a bad block — and normally you’d only find out when you tried to recover to it. ProxDR guards against that by re-scrubbing points in the background over their whole retention life: it re-reads each point’s data and compares it against the digest recorded when the point was first verified. If the contents have drifted, the point is automatically quarantined (flagged in the points list, with an alert) and can no longer be chosen for a failover or DR test. The points list also shows when each point was last content-checked, so you can see the scrub is keeping up. The result: you fail over to a point whose data is known-good now, not one that was merely good once.

Ransomware & corruption guard

A change-rate anomaly detector watches replication. If a guest suddenly looks mass-encrypted or corrupted, ProxDR pauses replication to preserve a clean pre-attack recovery point instead of overwriting it with the damaged data. Tune the policy in Settings.

Catch a frozen guest

Replication health is not the same as guest health. If a guest’s OS freezes or crashes, its QEMU process keeps running and its disk stops changing — so replication keeps succeeding on a static image and the guest’s RPO stays green. None of the usual signals go red, and a dead guest can hide behind a healthy-looking dashboard for days.

ProxDR closes that blind spot. It watches each running guest’s QEMU guest agent and, when the agent has been unreachable for more than a few minutes — with a debounce so an ordinary reboot doesn’t trip it — raises an agent-unreachable alert, independent of RPO. The alert clears on its own the moment the agent answers again.

When it fires, a one-click Fix agent button appears on the guest (and in the Tasks bell) that reboots the wedged guest to bring it back into service. It tries a QMP reset first — which keeps replication incremental — and falls back to a full power-cycle only if the monitor can’t be reached, then waits for the agent to respond. Like failover and failback, it stays available even under an expired license.

Recover from backups too

Beyond live replication, ProxDR can recover from Proxmox Backup Server and other backup-capable storages (directory, NFS, CIFS) — a fallback path when you need to restore from a backup rather than a replicated point.

Boot-time filesystem self-heal

A guest without the QEMU guest agent is captured crash-consistent — the equivalent of pulling the power — so its filesystem can need a journal replay or minor repair before it will boot cleanly. ProxDR can do that repair for you: on failover (a “repair filesystems” option) and automatically for every DR test, it runs an offline fsck — and, if the bootloader is missing, an offline GRUB reinstall — before the guest starts.

This is safe because it always runs on a throwaway clone of the recovery point, never the point or the live replica: a bad repair is discarded with the clone and your protected data is never touched. It turns a crash-consistent capture that would otherwise drop to a repair or GRUB-rescue shell into a guest that just comes up. (Windows/NTFS, encrypted, and nested LVM/ZFS volumes are skipped, never failed.) The health scrub also flags a guest whose filesystem looks dirty ahead of time, so you know before you need to recover.

Recovery operations

From Recovery operations you drive, per guest or pair:

• Failover — bring guests up at the recovery site.
• DR test — boot replicated guests in an isolated network to prove recovery without touching production or pausing replication. Clean up test VMs when done.
• Recovery points / health — inspect points and run readiness checks.
• Planned migration (Move) — a graceful, near-zero-downtime cutover to the other site.
• Failback — after a failover, return the guest to its home site. While it runs at the recovery site, ProxDR reverse-replicates changes back to the primary continuously, so failback applies only a small delta and is near-instant — forward protection then resumes on its own once the guest is home.
• Rebuild DR copy — the recovery path when a reverse lane stalls or diverges. One click (or proxdr dr reseed) re-seeds the DR copy from scratch so the next failback has a clean baseline. It replaces the old have-to-edit-the-database workaround.

Higher-risk operations can require dual-control (two-person approval) if you’ve enabled it in Settings.

Every operation runs on the server and gets its own live progress page — ordered steps, bytes transferred, timing, and any error — reachable from the Tasks bell or directly by URL. You can leave the page or close the browser; the operation keeps going, and it recovers on its own if the controller restarts mid-run.

You can start any of these from either site — ProxDR routes each to the controller that owns it, runs it exactly once, and the progress log names which controller ran it. Even with the primary completely down, the recovery site drives failover on its own. See Driving DR from either site.

Next: group guests into runbooks with Recovery Plans.