Recovery Plans

A Recovery Plan turns a pile of individual guests into a single, ordered runbook — so a real failover or a DR test runs as one orchestrated operation instead of a manual VM-by-VM scramble.

Building a plan

Create a plan and add the guests that make up an application or environment. Order them into stages to encode boot-order dependencies — for example, bring up the database tier, wait for it to be healthy, then the app tier, then the front-ends. Each stage completes before the next begins.

Running a plan

You can run a plan as either:

• a DR test — everything boots in an isolated network to prove recovery, non-disruptively; or
• a failover — the real thing, at the recovery site.

During a run you watch each member and stage progress live. Health checks can gate a stage so the run only advances once a tier is actually up.

When something fails

If a member fails mid-run, you can retry just that member without re-running the whole plan — every step is visible on the run’s live progress page as it happens, and a run survives a controller restart.

Coming back

After a failover, failback returns each guest to its home site. Because ProxDR reverse-replicates changes back to the primary the whole time you run at the recovery site, failback is near-instant — it applies only the delta accumulated since the failover, not a full re-copy — and forward protection resumes on its own once the guest is home.

Evidence

DR-test runs feed the Compliance page, which turns them into exportable RTO/RPO evidence for audits.

Next: Compliance.