Features

Everything you need to recover from a disaster

Purpose-built for Proxmox VE: replication, point-in-time recovery, testing, and orchestration in one web UI. Every plan includes the full feature set.

asternodis-nyc.local
Replication

Protected guests and their recovery point objective, across every DR Site Pair.

Protected
14
guests · 2 pairs
Meeting RPO
13/14
1 seeding
Recovery points
312
integrity-verified
GuestRPO targetRecovery pointsStatus
Uptime-Kuma
VMID 210 · NYC → SFO
1 min
building…
Initial sync
Full seed · 68% 210 MB/s · ETA 1m 58s · 21.8 / 32.0 GiB
db-01
VMID 101 · NYC → SFO
1 min
lag 11s
48 points verified
Replicating
app-02
VMID 102 · NYC → SFO
5 min
lag 1m 12s
36 points app-consistent
Replicating
mail-01
VMID 140 · NYC → SFO
15 min
lag 3m 40s
31 points verified
Replicating
file-svr
VMID 150 · NYC → SFO
1 hour
lag 22m
26 points verified
Replicating
The Replication page: protected guests, their recovery objective, and the live initial sync.

Replication

Ship only changed blocks to the recovery site, on any storage, at the RPO you set, to the pool you choose.

Near-continuous replication

VM and LXC container replication from every 10 minutes down to ~1 minute, on any storage backend, not just ZFS or Ceph.

Works on any storage

A storage-agnostic engine built on QEMU dirty bitmaps brings DR to LVM-thin and other backends Proxmox can't natively replicate.

VMs and LXC containers

Containers are protected at full parity with VMs (replication, non-disruptive testing, failover with re-IP, and failback), with application-consistent snapshots taken by freezing the container on the host, no in-guest agent required.

Put replicas where you want

Place each guest's recovery replica on any storage you choose (a directory, NFS or CIFS share, or a native ZFS, LVM-thin, or Ceph/RBD volume), per guest or per pair, with native snapshots for point-in-time recovery on block pools.

See every replica, live

Watch the first full sync with a real-time progress bar, transfer rate and ETA, then use the Shadows view to see every recovery replica across your sites and reclaim orphaned ones in one click.

No disruption to running guests

Replication reads changed blocks without pausing the guest and never locks its config. It shares the guest's QEMU monitor rather than holding it, so the VM's console stays usable even during a long first sync.

Recovery

Roll back to a known-good, continuously verified moment, and fall back to backups when there's no live replica.

Point-in-time recovery

Roll back to a known-good moment, not just the latest. Recovery points are integrity-checked at capture, application-consistent by default (quiesced through the guest agent for a VM, or the host's freezer for a container, with a per-guest opt-out), and pruned automatically on a grandfather-father-son schedule you set.

Restore in place, without failing over

Roll a guest back to an earlier recovery point on the primary itself: no failover, no topology change, nothing about where the guest runs is altered. One operation and one short outage: a stop and a boot, with the copy made while the guest keeps running. Available for VMs on every supported home storage, including directory, NFS and CIFS.

Continuous integrity scrubbing

Recovery points aren't verified just once. A background scrub re-reads each retained point over its whole life and quarantines any whose contents drift, catching silent bit-rot before you ever fail over to a bad point. It reads from its own isolated copy, so even a multi-hour check on a large guest never pauses replication. Points on directory, NFS and CIFS recovery replicas are covered too, and a Repair now button proves, or clears, a standing filesystem warning on a disposable copy of the point, without touching the point itself.

Ransomware & corruption guard

A change-rate anomaly detector pauses replication when a guest looks mass-encrypted or corrupted, and tells the recovery site to hold the line too: no new recovery point is captured from the suspect state, and nothing older than the detection can age out of the retention schedule while you decide. The clean pre-attack point is still there when you reach for it, and Restore in place puts the guest back onto it without a failover. The review screen weighs what the guest shipped against what it stores and its free space, and says whether the burst matches a routine disk trim, so a trim is quick to clear; a guest that trips it on a known, recurring pattern can be exempted individually, with a reason.

Catch a frozen guest

Replication health isn't guest health: a crashed or frozen VM keeps replicating a static disk, so its RPO stays green while it's dead. Asternodis watches each guest's agent, alerts when one goes unreachable, and reboots it back into service in one click. And when the agent is missing in the first place, Asternodis installs it into the guest at its home site on request, in one of two ways. Live, over SSH with a guest login you supply: the guest keeps running, and the agent answers as soon as the install finishes if its channel is already enabled, or after the guest's next restart if not. Or by restart: no login needed, but the whole disk is re-copied on the next sync, a cost Asternodis asks you to acknowledge first.

Boots even from a dirty capture

Before a recovered guest starts, Asternodis can check and repair its filesystem (and reinstall a missing bootloader) on a throwaway clone of the recovery point, never the protected data. An agent-less guest captured crash-consistent still comes up instead of dropping to a repair shell. A recovered Linux or Windows copy with no working guest agent gets one installed before it boots (on by default for every DR test and failover), so the copy comes up with a working agent without you doing anything.

Keep your IPs, or rewrite them

Re-IP profiles rewrite a guest's address, gateway and DNS on failover when the recovery site uses a different subnet. For apps that hardcode addresses and can't be re-IP'd, a DR edge gateway routes an isolated bridge mirroring the production subnet instead. Recovered guests boot on their original IPs, with outbound NAT set up automatically and the port-forwards you declare programmed on every failover.

Recover from backups too

No live replica? Fall back to a restore from Proxmox Backup Server, or any backup-capable storage (dir/NFS/CIFS), right from the same console.

Testing & orchestration

Prove recovery without touching production, then fail over (and back, near-instantly) with ordered, health-gated runbooks.

Non-disruptive DR testing

Boot replicated VMs on an isolated DR-test network you map to prove recovery. Production keeps running, and Asternodis warns you when a test would not be fenced. Only the guest under test defers its replication, and only while its test copy is built and booted; every other guest keeps replicating. Schedule tests and export the evidence.

Orchestrated failover

Recovery plans with ordered boot groups, health gates, re-IP and network mapping, so an application comes back in the right order, not VM-by-VM by hand.

Near-instant failback

While your recovered guests run at the recovery site, Asternodis reverse-replicates changes back to your primary continuously, so returning home applies a few MiB of delta in seconds instead of re-copying the whole disk. This now reaches single-node thick LVM too, including LVM on an iSCSI LUN (block storage with no native snapshot, where the lane activates the stopped home volume before it reads it), not only ZFS, LVM-thin, Ceph and file replicas. A running guest is what makes that tracking possible: a copy you deliberately leave powered off has nothing tracking its changes, so its failback reads and compares the whole disk instead (safe, just not instant). If the original home node is degraded or gone, fail back to a different healthy node in the same cluster instead. A VM on shared storage moves there copying nothing, and one on node-local storage (ZFS, LVM-thin or a local directory) gets a fresh-disk copy.

Live progress for every operation

Failover, failback, DR test and planned migration each get their own live page: ordered steps, bytes transferred, and any error. Start it on the server, then close the browser; it keeps running.

Drive it from the command line

A CLI, asternodis dr, runs recovery operations from a terminal or a script (and a failover prints the same go/no-go preflight the web UI does before it proceeds), so DR fits into your own automation, not only the console.

Go / no-go preflight

Capacity, storage, machine-type compatibility and the recovery network are checked per guest before failover, on real evidence: a target bridge that does not exist on the node that will run the guest is flagged as a definite failure, not an unverified maybe. A failed preflight never silently blocks a recovery; you acknowledge it first, so failover lands, even across Proxmox versions.

Cross-site planned migration

Move a running VM between sites with a graceful cutover and zero data loss: the guest goes down while its final changes ship, and stays down until you commit it on the new site, or roll back any time before you commit.

Scale & governance

Run DR across many sites with the resilience, access controls, approvals, and audit trail teams need.

Multi-site & DRaaS

Two-site, many-to-one hub (DRaaS), and mesh topologies, managed from one web UI at every site.

Operate DR from either site

Both sites run the identical web UI. Drive every recovery operation from whichever controller you can reach. Asternodis routes each action to the site that owns it, so two operators can't cause a split-brain, and the recovery site stays fully in control even with the primary completely down.

No single point of failure

A full instance runs at each site. If your primary site is gone, you drive recovery from the surviving side.

Self-healing controller

A failover cut short (by a lost peer link or a controller restart) is detected, and its guest is restarted at the primary automatically once the primary answers. A stalled reverse lane retries transient faults and re-seeds itself when the two sites disagree on its baseline; a fault it cannot settle safely stops the lane and raises a critical alert with the reason. A controller restart never resumes an operation on its own: the run is marked interrupted with its step log kept, so you see exactly where it stopped before you run it again. And if a DR copy diverges, you rebuild it from the UI. No database surgery.

Alerts that lead somewhere

Every alert names the guest, says plainly what it means, and links to the page where you act on it. Silence the ones you've already judged, or clear a whole firing set in one click, so the list stays a list of things that need you. The Replication page's banner surfaces only the alerts that mean a recovery won't work, and an alert fires within minutes when the link to your paired site degrades or drops.

Enterprise access & audit

Role-based access, optional two-person approval for failover, and a tamper-evident audit trail, with exportable compliance reports: the full audit log as CSV, DR-test evidence, and a control-coverage matrix that maps that evidence to NIST SP 800-53, ISO/IEC 27001, BSI IT-Grundschutz, NIS2 and CMMC Level 2 controls.

Fail-safe licensing

Licenses are counted in DR Site Pairs, with business tiers sized by protected nodes, never per VM or per seat. Each controller counts the pairs and protected nodes it holds against the license, shows your pair usage right where you create pairs, and won't create or join a pair past the license's allowance. And if a license or trial lapses, recovery never does: scheduled replication pauses, and adding a pair, protecting a new guest, running a DR test and starting a planned migration are blocked, but failover, failback and abort stay available. A paid license is verified offline from a signed token: a controller activated with a license key renews it at least daily while it can reach the activation service, and each token the service issues runs 30 days or to your license's paid-through date, whichever comes first. You're warned 14 days before the token lapses, and everything keeps working normally through a 7-day grace period after.

asternodis-sfo.local

Recovery points: VMID 210

+ Snapshot now

Roll back to a known-good moment. Points are integrity-checked at capture and continuously re-scrubbed over their whole retention life.

Today · 14:00 hourly
verified app-consistent content-checked 2h ago
Verify DR test
Today · 13:00 hourly
verified app-consistent content-checked 3h ago
Verify DR test
Today · 00:00 daily
verified content-checked 14h ago
Verify DR test
Jul 21 · 00:00 daily
verified app-consistent content-checked 1d ago
Verify DR test
Jul 15 · 00:00 weekly
quarantined content digest changed since last check (bit-rot)
Verify DR test
Jul 08 · 00:00 weekly
verified content-checked 2d ago
Verify DR test
Continuously scrubbed recovery points, one auto-quarantined after silent bit-rot.
asternodis-nyc.local

Failback: Uptime-Kuma VMID 210

In progress · 00:16

Runs on the server. You can leave this page or close the browser; it won't stop.

Near-instant failback. Continuous reverse sync kept asternodis-nyc current while you ran at the recovery site, so returning home applies a 5.2 MiB delta instead of re-copying the full 32 GiB disk.

Steps
  1. Quiesce DR copy at asternodis-sfo 20:14:02
    guest paused
  2. Apply reverse-synced delta to primary disk 20:14:05
    5.2 MiB applied
  3. Verify primary disk 20:14:14
    scoped extents · matched · 9s
  4. Fence DR copy & boot guest at asternodis-nyc
    starting…
  5. Resume forward protection (NYC → SFO)
Near-instant failback: a few MiB of reverse-synced delta, live step by step.

Prove it in your own environment

Start a free 14-day trial with the full feature set. No feature is held back on any plan.