How to Back Up CloudStack: Host-Assisted CBT for QCOW2/NFS, ZFS, and Linstor/DRBD

The CloudStack backup problem: no native CBT

On VMware, backup vendors have it easy: vSphere maintains a change map per virtual disk and hands it over through an API. On KVM — and therefore on Apache CloudStack — no platform-wide equivalent exists. Whoever wants incremental backup has to know, by some other means, which blocks changed since the last job. Most products resolve that tension in one of two unsatisfying ways:

Full-image copies: fine until the second terabyte

Without a change map, the safe answer is to read everything, every time. A 2 TB volume with 1% daily churn gets read in full nightly to capture 20 GB of change. Multiply by a few hundred VMs and the backup window collides with production hours, primary storage spends its IOPS feeding the backup system, and the only lever left is backing up less often — which is just a worse RPO wearing a schedule.

Per-VM guest agents: the operational tax

The other escape hatch is an agent inside every guest doing the tracking and often the data movement too. Now there is software to deploy, patch, monitor and credential in every VM, on every OS in the estate — and tenants in a service-provider cloud may not even let you in. Agent sprawl is how backup becomes a second infrastructure project.

The host-assisted paths: CBT for QCOW2/NFS, ZFS and Linstor/DRBD

The better answer is to solve change tracking per storage path, at the infrastructure layer, without installing backup software inside protected guests. For qualified QCOW2/NFS, ZFS, and LINSTOR/DRBD modes, Sendense uses snagent on the KVM host to prepare snapshots and supply extent information:

• QCOW2 on NFS (and local): the qualified snagent host-assisted path provides snapshot preparation, changed-block tracking, and consistent capture, with no backup component inside the protected VM.
• ZFS-backed primary storage: the qualified snagent host-assisted path prepares the host-side snapshot and supplies changed extents, with nothing installed inside protected guests.
• Linstor/DRBD: the qualified snagent host-assisted changed-block path respects storage locality and multi-tenant boundaries.

These modes are guest-agentless: no backup data component is installed inside each protected VM. They are still host-assisted, because snagent must be healthy and correctly placed on the KVM hosts. If that required agent path is unavailable, the job can fail rather than automatically falling back to a full-source read.

Other storage types: what full-source-read protection means

Some CloudStack estates run storage types with no qualified native extent map or CBT technology: Ceph RBD, raw block, XCP-ng storage repositories, provider-specific arrays and mixed edge storage. Sendense protects supported paths by scanning and reading the full source, then lets EBA deduplicate the retained repository data.

• Be clear about source I/O: without a qualified native or host-assisted change map, every backup scans and reads the full source.
• Never in the data path: backup data does not flow through the guest. Transfer remains snapshot-driven at the hypervisor data layer, exactly as on the native paths.
• RAW Block Sendense CBT: Eligible protection patterns using version-aware EBA repositories retain the full source scan and read. The first and explicitly forced fulls remain genuine fulls; suitable later recovery points can be represented as synthetic incrementals when eligibility and integrity checks pass.

The full named compatibility reference is maintained on the CloudStack storage backends page, including Ceph RBD, raw block, CLVM, NFS/QCOW2, iSCSI, Fibre Channel, StorPool, PowerFlex, VMware storage and XCP-ng storage repositories.

Where the CloudStack B&R Framework fits

Apache CloudStack also has a Backup and Recovery Framework. It is useful to understand what that means: it is a provider-plugin orchestration surface for backup offerings, schedules and restore actions, not a universal CBT data path across every CloudStack storage backend.

Sendense does not depend on that framework. Sendense uses its own CloudStack-aware protection plane — SNA backup proxies, qualified native paths, CloudStack-aware full-source reads and EBA repositories — so the storage coverage decision is not limited to the standard B&R provider list. The fuller technical position is on Sendense and the CloudStack B&R Framework.

The data path: snapshot-driven, at the hypervisor layer

On every storage class, the actual backup data moves the same way: CloudStack snapshot coordination produces a point-in-time image, and Sendense reads from the hypervisor data layer. Qualified native paths can read changed blocks; other supported paths scan and read the full source on every run. Guests do not serve backup I/O; tenant networks do not carry it.

Consistency is a choice per workload. Snapshot capture alone is crash-consistent — equivalent to a power-cut, which journalling filesystems and most applications recover cleanly. Installing qemu-guest-agent upgrades that to application-consistent: filesystems are frozen and thawed around the snapshot, so databases and transactional systems restore without replay surprises. For anything that speaks SQL, run the guest agent.

Source reads and EBA repository efficiency

Qualified native paths can reduce source reads by transferring changed blocks. Other supported paths scan and read the full source on every run. In both cases, recovery points land in EBA — Enterprise Block Archive — where they are deduplicated, compressed and encrypted, with immutable retention and legal-hold controls, on repository storage including S3-compatible object stores. Deduplication keeps repeated full-read backups from retaining duplicate block content, but it does not reduce the scan or read performed against the source.

Restores: full VM, file-level, cross-platform

A recovery point is only as good as its exits. From the same CloudStack backup you can restore the full VM, recover individual files, AD objects or SQL databases without a full restore, or restore cross-platform onto another supported target with inline conversion — the same mechanism that powers VMware exit migrations, pointed the other way. AsureDense attaches proof-of-recovery evidence to recovery points, so "the backup completed" and "the backup restores" stop being different claims.

Protecting a CloudStack zone, in five steps

• 1. Deploy the appliances — outbound-TLS site connectivity, no inbound firewall rules; multi-site deployment is a ~30-minute job.
• 2. Connect CloudStack — Sendense discovers zones, hosts, VMs and, critically, which primary storage each volume lives on.
• 3. Let the storage path select itself — qualified Linstor/DRBD, ZFS, and QCOW2/NFS volumes use snagent host-assisted changed-block paths; other supported paths use a CloudStack-aware full-source scan and read under the same Sendense operating model.
• 4. Set policy — schedules, retention, immutability and repository targets, tenant-aware for service providers.
• 5. Validate a restore — run one full-VM restore and one file-level recovery before you call anything protected. Evidence beats assumption.