What is XCP-ng?
XCP-ng is an open-source, enterprise-grade virtualization platform built on the Xen hypervisor. Developed by Vates and incubated within the Xen Project under the Linux Foundation, it began as a fork of Citrix XenServer and now ships 8.3 LTS as its long-term release.
Every host runs a control domain called dom0, the XAPI toolstack and the device drivers. Clients reach the whole pool through a single Xen API connection to the pool master, managed from a console, the API or the command line.
VM disks live in Storage Repositories as virtual disk images, and the platform is pool-oriented by design. A sound XCP-ng backup plan therefore covers the virtual machines, the pool metadata describing them, and the management layer that runs the jobs.
Understanding XCP-ng Backup Architecture
XCP-ng ships no backup scheduler of its own. Jobs are handled by Xen Orchestra, the management plane developed alongside the hypervisor, so XCP-ng backup architecture comes down to what the platform exposes to that engine.
What Needs to Be Protected in XCP-ng?
The project documentation is direct about the scope of an XCP-ng backup: your VMs, the pool metadata, and the Xen Orchestra configuration itself. With those three covered, any host can be reinstalled from the ISO.
Pool metadata is the layer administrators forget, yet the XAPI database holds VMs, Storage Repositories, networks and how they connect. Losing hosts while the storage survives is realistic, and without that database the surviving disks are anonymous files.
How XCP-ng Backup Works
Xen Orchestra backup is agentless, meaning nothing runs inside the guests. A full run takes an XCP-ng snapshot, exports the allocated blocks as a self-contained XVA archive, then deletes it, so the VM keeps running the whole time.
That XCP-ng snapshot shares storage with the original disk, and deleting it triggers a coalesce, which is costly on thick-provisioned repositories. File-based thin storage such as local EXT, NFS or XOSTOR is therefore recommended for XCP-ng backup hosts.
NBD is the faster alternative transfer path, moving data over a direct connection to the host running the VM instead of through the XAPI export handler. QCOW2 disks require NBD, or each XCP-ng incremental backup falls back to a full transfer.
Backup vs. Snapshot vs. Replication
These mechanisms are often treated as interchangeable, and that confusion causes real outages. An XCP-ng snapshot lives on the same storage as the original disk, so losing that disk or its Storage Repository destroys every XCP-ng snapshot with it.
Replication writes a bootable standby copy to a different Storage Repository, pool or site. Xen Orchestra blocks the start operation on those replicas so a reboot cannot bring them up accidentally, and it disables HA on them as well.
| Mechanism | Where the copy lives | Survives loss of the source SR? | Typical use |
|---|
| Rolling snapshot | Same SR as the original disk | No | Rollback before a risky change |
| Full/incremental backup | Backup repository (NFS, SMB, S3) | Yes | Recovery from deletion, corruption or ransomware |
| Full/incremental replication | Another SR, pool, or site | Yes | Failover with a bootable standby copy |
| Pool metadata backup | Backup repository | Yes | Rebuilding a pool after total host loss |
How to Design an XCP-ng Backup Strategy
A workable XCP-ng backup strategy starts from two numbers rather than a feature list. Define how much data you can lose and how long you can be down, then pick the mechanisms that satisfy those numbers at a cost you accept.
RPO and RTO
Recovery Point Objective is the maximum acceptable data loss, while Recovery Time Objective is the maximum acceptable downtime. Both are business decisions, and together they determine whether a nightly job suffices or your XCP-ng disaster recovery plan needs replication every ten minutes.
Backup and replication answer different questions. Backups provide history and granularity, since any retained point can be restored. Replication provides speed, because the standby copy already sits on target storage and needs no restore phase.
| Tolerable data loss (RPO) | Recommended approach | Notes |
|---|
| 24 hours or more | Nightly XCP-ng incremental backup | Simplest and cheapest per VM |
| 1–12 hours | Incremental backup plus scheduled full replication | Storage heavy on the destination |
| 10–60 minutes | Incremental replication on critical VMs only | Xen Orchestra supports intervals from 10 minutes |
| Near zero | Application-aware or CDP tooling | Outside the scope of native XCP-ng tooling |
Backup Frequency
Frequency is a storage and bandwidth decision as much as a protection decision. An XCP-ng incremental backup is fast and small, so it tolerates high frequency, while a full XCP-ng VM backup job spends bandwidth on every run and deduplicates nothing.
Vates recommends avoiding schedules that overlap heavy VM workloads, and notes that backup runs are network intensive. A weekend full export followed by nightly deltas keeps the expensive operation in the quietest window of the week.
Backup & Replication
Most infrastructures do not choose between the two. A documented pattern pairs incremental backups for everything with incremental replication for critical VMs and a mirror elsewhere, so each mechanism carries a different part of the XCP-ng disaster recovery plan.
Sequencing matters when both run against one pool. Xen Orchestra offers backup sequences that chain existing schedules so they execute in a fixed order, preventing overlapping jobs from competing for dom0 resources before the next run begins.
Multiple XCP-ng Pools
Xen Orchestra manages several pools from one console, so a single control plane can protect a fleet rather than one cluster. Larger estates can offload XCP-ng VM backup traffic to proxies closer to each pool, keeping transfers off the management network.
Failure domains are the real constraint. If production and the Xen Orchestra appliance share a power or network boundary, one incident removes both your workloads and the tool that restores them, so the XCP-ng disaster recovery site needs its own management plane.
Offsite Protection
The second copy has to leave the failure domain, and a mirror job is the simplest way to get it there. Mirror backups replicate one repository to another with independent encryption, compression or retention, so cheaper storage can hold the long-term copy.
Object storage is the usual destination, and Xen Orchestra writes to S3-compatible providers and Azure Blob Storage. Vates classifies providers by support tier, so test the endpoint before an XCP-ng disaster recovery site depends on it.
Best Practices for XCP-ng Backup
The practices below come from documented platform behaviour rather than preference. Each one maps to a failure mode that has caught XCP-ng administrators in production routinely, and each is cheap to adopt in advance.
Keep the Delta Chain Short
An XCP-ng incremental backup chain is only as strong as its weakest delta. Xen Orchestra merges the oldest delta into the full backup when retention is exceeded, but corruption in one delta can still propagate past the reference XCP-ng snapshot.
Never Delete the Reference Snapshot
Incremental jobs keep the latest XCP-ng snapshot of every VM and use it as the reference for the next delta, rather than deleting it after export. Removing it breaks the XCP-ng backup chain and forces a new full export.
Verify Instead of Assuming
A backup that has never been restored is a hypothesis, and Xen Orchestra ships a health check for it. After each run, it restores the backup, boots it, and marks it healthy only when the guest tools load — nothing an XCP-ng snapshot can confirm.
Plan Capacity on Both Sides
Backup planning covers two storage systems, and usually only one is discussed. On the source side, an XCP-ng incremental backup leaves data on the same Storage Repository as the VMs, so a nearly full repository fails XCP-ng snapshot creation first.
Encrypt and Immutable: What Matters
Encryption in Xen Orchestra backup is compatible with block-based repositories, because an XCP-ng incremental backup stores encrypted data as blocks rather than one VHD file. ChaCha20-Poly1305 has been the default since February 2025, replacing AES-256-GCM and its 64 GiB ceiling.
Common XCP-ng Backup Mistakes
Most incidents trace back to a small set of recurring assumptions rather than unfamiliar failures. Recognising them before an outage is considerably cheaper than rediscovering them in the middle of a live production recovery window.
Treating Snapshots as Backups
A rolling XCP-ng snapshot is a fast rollback point, not a backup. It shares storage with the original disk, so it only protects against a bad patch, and a storage failure removes the VM and its XCP-ng snapshots together.
Forgetting Pool Metadata
Restoring VMs without the pool database turns a clean recovery into a manual rebuild. The metadata job is small and quick, yet it is routinely skipped because nothing visibly breaks while it is missing from the schedule.
Running Full Backups Only
Full backups have one real advantage: each archive is self-contained, so a single XCP-ng VM backup restores the whole VM. The cost is that every run re-exports everything, and file-level restore needs an XCP-ng incremental backup.
Assuming Native Tooling Is Application-Aware
Vates states the position plainly: Xen Orchestra backup works at the VM level and does not perform application-aware protection. There is no dedicated Exchange protocol, no mailbox-level restore and no in-guest database agents for SQL Server, Oracle or other databases.
Quiesced VSS snapshots were also removed from the platform, so the alternatives are a RAM-enabled checkpoint, available from XCP-ng 8.0, or an offline backup that stops the VM before export. Neither matches true in-guest application consistency.
Ignoring the Storage Repository Configuration
Snapshot cost depends on provisioning. On thick-provisioned block storage, the changed blocks an XCP-ng VM backup must retain consume space aggressively, while thin-provisioned file-based repositories cost far less, which is why the platform recommends them.
Disk format matters at scale too. VHD is limited to 2 TiB per disk, and larger disks require a block-based backup repository. QCOW2, generally available in XCP-ng 8.3 LTS, raises that ceiling to 16 TiB.
XCP-ng Native Backup Methods with Xen Orchestra
Xen Orchestra is the native, fully open-source Xen Orchestra backup engine for XCP-ng, bundled with every Vates VMS subscription. It offers several distinct job types, and choosing between them is the core of an XCP-ng backup design.
| Mode | What it writes | Destination | Best suited to |
|---|
| Full backup | One self-contained XVA archive per run | Backup repository | Small estates, simplest restore |
| Incremental backup | A key backup plus changed-block deltas | Backup repository | The default for most VMs |
| Full replication | The complete VM, streamed | Another SR or pool | XCP-ng disaster recovery with a modest RPO |
| Incremental replication | Only the changed blocks | Another SR or pool | Low RPO disaster recovery |
| Mirror backup | A second copy of a repository | A second repository | 3-2-1 and offsite retention |
| Metadata backup | The XAPI database and XO config | Backup repository | Every environment, always |
Full VM Backup
A full Xen Orchestra backup exports the complete VM, all of its disks and its configuration, to a backup repository on every run. Each run produces a single self-contained XVA archive, so the restore model stays simple.
Incremental Backup
An XCP-ng incremental backup, historically called continuous delta backup, exports the complete disks once and then only the blocks changed since the previous run. That first XCP-ng VM backup is the key backup, compared against a reference snapshot each time.
The design makes a high-frequency XCP-ng incremental backup schedule affordable and enables the features administrators request. File-level restore works from those deltas, and a differential restore can rebuild a large VM in place by reading the XCP-ng snapshot.
Full Replication
Full replication, previously labelled Disaster Recovery, keeps a complete ready-to-boot copy of each VM on another Storage Repository. Export and import happen in a single streaming pass with no intermediate file, which suits XCP-ng disaster recovery with a tight RTO.
Incremental Replication
Incremental replication, previously Continuous Replication, sends only changed blocks after the initial transfer. Vates describes it as agentless and free of storage vendor lock-in, with a recovery point objective for XCP-ng disaster recovery from ten minutes.
Metadata Backup
A metadata backup is a small job with an outsized role. It dumps the pool XAPI database covering VMs, Storage Repositories and networks, then exports the Xen Orchestra configuration with its users and jobs. Both belong on a schedule.
Limitations of Xen Orchestra
The limitations are documented rather than hidden, and each points to a deliberate design choice. Xen Orchestra backup protects one platform, XCP-ng, and performs no application-aware backup: no Exchange protocol, no mailbox-level restore, no in-guest agents.
Operational limits are equally specific. Disks over 2 TiB require a block-based repository, QCOW2 disks need NBD for incremental runs, SMB suits only small VMs, and encryption cannot be changed once a repository holds data.
How to Use Vinchin for XCP-ng Environment Protection
Native XCP-ng tools deliver basic VM protection, yet many enterprise teams hit hard limits when building robust ransomware defence, cross-platform backup and granular disaster recovery. Vinchin Backup & Recovery is officially listed as a compatible third-party solution within the Vates backup ecosystem, filling those critical protection gaps for XCP-ng environments.
Where Vinchin Fits in an XCP-ng Environment
Xen Orchestra offers solid native VM backup for standalone XCP-ng deployments. But for organisations running mixed virtualisation stacks, Vinchin brings powerful application-consistent protection, flexible disaster recovery workflows and unified central management for all workloads, not just XCP-ng VMs. Vinchin fully supports XCP-ng 7.4, 7.5, 7.6, 8.0, 8.1, 8.2 and 8.2.1.
Core Capabilities for XCP-ng VMs
Cut backup storage consumption and shorten backup windows with Vinchin's forever incremental backup. Take one initial full backup of your XCP-ng VM, after which only changed blocks are captured. Synthetic full backups are automatically assembled at restore time, while changed block tracking precisely pinpoints modified data blocks to minimise backup traffic and storage overhead.
Reduce business downtime dramatically with enterprise-grade recovery capabilities. Vinchin’s instant recovery can power up an XCP-ng VM from backup in as fast as 15 seconds by mounting backup storage via NFS, delivering fast workload restoration for your XCP-ng disaster recovery strategy.
Getting an XCP-ng Pilot Running
Check simple prerequisites before deployment: ensure your Vinchin backup server can communicate with your XCP-ng pool over ports 80, 443 and 29202, and prepare pool master credentials to start your XCP-ng backup trial.
Onboarding is straightforward: register your pool master via IP or domain name, authenticate all hosts, and create custom backup jobs. You can configure full, incremental or differential schedules, plus built-in data deduplication, compression, AES encryption and GFS retention policies to meet compliance requirements.
No need for a full rip-and-replace. Run Vinchin in parallel with your existing native backup jobs on a small subset of production VMs. Validate restore performance against your RPO/RTO targets, launch a free trial and test how Vinchin protects your unique XCP-ng workloads and hardware.
FAQ
Q1: Can I back up XCP-ng VMs without Xen Orchestra?
A1: Manual exports are possible through the Xen API or command line, but you lose scheduling, retention and incremental chains. Vates lists officially compatible XCP-ng VM backup products such as Vinchin.
Q2: How often should I back up XCP-ng VMs?
A2: Frequency follows your recovery point objective. Nightly XCP-ng incremental backup jobs suit a twenty-four-hour tolerance, while critical VMs may need incremental replication at intervals from ten minutes, and a full XCP-ng backup belongs in a low-I/O window.
Q3: Do XCP-ng snapshots count as backups?
A3: No. An XCP-ng snapshot lives on the same Storage Repository as the original disk, so a storage failure destroys the VM and every XCP-ng snapshot together. Snapshots suit rollback before a risky change; only copies on separate storage survive.
Q4: How long can an XCP-ng incremental backup chain be?
A4: There is no hard platform limit, but longer chains increase exposure to corruption propagating forward. Xen Orchestra exposes a key backup interval setting that caps chain length and forces periodic full exports, and Vates suggests starting near twenty.
Q5: Does Xen Orchestra support application-consistent backup?
A5: Only up to a point. Vates states that Xen Orchestra backup works at the VM level without application-aware backup. Since quiesced VSS snapshots were removed from the platform, your options are a RAM-enabled checkpoint from XCP-ng 8.0, or an offline backup.
Conclusion
A reliable XCP-ng backup strategy rests on facts rather than features. Know what the platform actually protects, choose mechanisms that meet your recovery objectives, and verify that restores work before you need them. VMs, pool metadata and the management layer all need coverage for XCP-ng disaster recovery to hold.
The native tooling is capable and documented, including its limits. Xen Orchestra backup covers most VM-level requirements and protects the orchestration layer through metadata jobs. Where XCP-ng VM backup needs application-aware recovery or multi-platform coverage, Vinchin extends the same infrastructure.
