📚 Browse docs

Introduction

Asternodis 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.

Asternodis ships as a single Go binary that serves both the daemon and the web UI. There is no proprietary agent in your guests or on your hosts: Asternodis works through Proxmox’s own API, SSH, and (in VMs that run it) the standard qemu-guest-agent, which Asternodis can install where it is missing. Connecting a cluster with its SSH credentials authorizes an SSH key for Asternodis on its nodes and, unless you supply an API token, creates one. Asternodis also installs the standard Debian packages it needs, such as qemu-utils, on a node that lacks them.

Core concepts

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

  • Site: one Asternodis 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 Asternodis licenses and the unit you fail over. A pair can protect any number of guests; business tiers also cap the number of protected nodes (see License).
  • Protected guest: a VM or container you’ve enrolled for replication on a pair. Asternodis captures near-continuous recovery points for it.
  • Controller: the Asternodis 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 an Asternodis controller (Inventory).
  2. Pair your production controller with a recovery-site controller (Site Pairs).
  3. Protect the guests you care about; Asternodis replicates them continuously.
  4. Test recovery in an isolated network whenever you like, with 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.