XCP-ng VM Backup and Disaster Recovery (Xen Orchestra)

XCP-ng is the open-source hypervisor. Its own documentation describes only a small set of backup tools in the core platform: a command to dump the pool database (xe pool-dump-database) and restore it, and a host backup command for the control domain. The docs call these useful for pool metadata and for hardware maintenance, and they say that a clean reinstall plus a metadata restore is often simpler and safer than a host restore.

For virtual machines, the XCP-ng documentation points to Xen Orchestra, which it presents as the officially supported and most integrated backup solution. Third-party products also exist. The XCP-ng documentation notes that some of them work through agents inside each VM, which gives up the tight integration with Xen Orchestra. As of October 2026, XCP-ng 8.3 is the current long-term support release (full support until 30 November 2028, according to the XCP-ng release page), and the Xen Orchestra blog lists version 6.9 as the latest release, dated 30 September 2026.

Xen Orchestra is open source under the AGPLv3 and is also sold as a supported appliance called XOA, according to the Xen Orchestra entry in the Open-Source Backup Ledger. Our article on managing XenServer and XCP-ng with Xen Orchestra explains the console itself.

Xen Orchestra works at the hypervisor level, so you do not install an agent in each virtual machine. The vendor's overview page describes seven job types.

Older documentation and the XO 5 interface use the names Disaster Recovery for full replication and Continuous Replication for incremental replication, so you will meet both sets of names in forum posts and older guides.

Snapshots are the starting point for the other types, but they are not backups. The Xen Orchestra documentation says so directly: snapshots live on the same storage as the VM, so a snapshot shares its fate with the disk it came from. A real backup or replica must live elsewhere.

For incremental backups, the first run exports a full copy. Each later run compares the VM's disks with a reference snapshot from the previous run and sends only the difference to the backup repository. The job keeps that reference snapshot on the host, and the documentation warns not to delete it. Retention is handled by merging the oldest delta into the full backup on the repository, so the hosts are not involved in the merge. Changed-block tracking can drop the reference snapshot's data and leave only a small metadata disk on the storage repository. A transfer option called NBD connects directly to the host that runs the VM, and the documentation says qcow2 disks need it for incremental backups, otherwise each run becomes a full transfer. The vendor also suggests a key backup interval, with a value around 20 given as an example, so a damaged link in a delta chain cannot spread far.

Incremental replication takes one replication snapshot per run and uses those snapshots as the common base for the next delta. It is agentless and needs no intermediate storage. Full replication exports the whole VM each time and streams it straight into the destination storage, so its practical RPO depends on how long a full export takes.

Xen Orchestra's backup strategy guide lists these backup repository types: NFS, SMB, S3-compatible object storage, Microsoft Azure, Azurite and local storage, which the guide marks as not recommended. Encryption is opt-in and configured per repository. Backups are compressed on the host with gzip or zstd. For immutable copies the documentation refers to S3 Object Lock, and Xen Orchestra does not set the lock period itself, so you configure retention on the storage side.

Long-term retention can keep daily, weekly, monthly and yearly restore points per repository. The mirror backup type exists to move backups from a nearby NFS share to larger, cheaper storage with longer retention. Together with a second site, that gives you the layout described in the 3-2-1-1-0 rule.

Restore a whole VM from a full or incremental backup. For an incremental backup, Xen Orchestra reads the chain and rebuilds the VM, and you can live-mount a disk read-only from the backup to reach files.

File-level restore works on incremental backups, for a single virtual disk. The documentation lists data deduplication, LDM and ReFS as not supported.

For failover from a replica, pick the newest replica on the disaster recovery pool, clone it (the recommended step) or remove its start block, fix network settings and start it. Replicas are powered off and protected from accidental start. Two machines with the same static address will conflict if they run at once.

A health check restores the backup, boots it and waits up to 10 minutes for the guest tools to load. It is a built-in restore test and complements the checks in our backup testing guide.

Start from the recovery point and recovery time you need, as described in RPO versus RTO. The vendor's guide suggests a nightly snapshot with retention of 7 for frequently changing VMs as a first step, incremental backup as the default for most VMs, and incremental replication for the few VMs whose data loss tolerance is measured in minutes. Full replication fits a modest RPO. Add mirror backup when you need an offsite copy. Our article on XCP-ng business continuity discusses the wider plan, and which XenServer backup method minimizes downtime compares the methods by recovery time.

In the Open-Source Backup Ledger, Xen Orchestra's backup features have a capability score of 70.4 out of 100 and a Ledger Index of 67.0, which puts it second of 16 projects. The Ledger's reading is that it is a complete backup and DR product for Xen-based VMs, but it protects only those VMs and has no tape or physical server agents. In the VM Platform Ledger, the XCP-ng report gives the platform a capability score of 63.1 and a Ledger Index of 61.2, and it records that the data protection and DR domain rose in 2024 with changed-block tracking and immutable and mirror backups.

Does XCP-ng include backup?

XCP-ng includes VM snapshots and command-line tools to back up the pool database and the host. For VM backup and disaster recovery you use Xen Orchestra, which the XCP-ng documentation presents as the officially supported option.

What is the difference between a backup and a replica in Xen Orchestra?

A backup is stored as files on a backup repository and restored when needed. A replica is a powered-off copy of the VM on another storage repository that you can clone and start quickly, which makes it a disaster recovery tool.

Can Xen Orchestra back up to S3 or a NAS?

Yes. The vendor lists NFS, SMB, S3-compatible storage, Microsoft Azure and Azurite as backup repository types. Local storage is possible but marked as not recommended.

Are snapshots enough to protect XCP-ng VMs?

No. Snapshots share storage with the VM disk, so they do not survive a storage failure. The vendor's own documentation states that snapshots are not backups.