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.
A failover run first shows the same go/no-go preflight across the plan’s guests; one that fails or couldn’t run must be acknowledged before the run starts (see Replication & recovery operations).
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 Asternodis 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.
This assumes the recovered guest is running at the recovery site: a live guest is what lets Asternodis track its changed blocks. If you fail over with Power on unchecked, or stop the DR copy afterwards, there is nothing tracking changes: the copy is safe and nothing has been lost, but proving the two disks match means reading and comparing the whole disk, so that failback takes as long as a whole-disk read rather than seconds.
Evidence
DR-test runs feed the Compliance page, which turns them into exportable RTO/RPO evidence for audits and maps that evidence onto the control frameworks you are assessed against.
Next: Compliance.