How to Back Up CloudStack: Agentless 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 native paths: agentless CBT for QCOW2/NFS, ZFS and Linstor/DRBD

The better answer is to solve change tracking per storage path, at the infrastructure layer, so guests are never touched. Sendense built exactly that for the three storage families that dominate CloudStack KVM estates — each one agentless and CBT-enabled:

• QCOW2 on NFS (and local): live snapshots with changed-block tracking and atomic multi-disk capture — incrementals read only changed blocks, with no in-guest client required.
• ZFS-backed primary storage: native storage behaviour drives point-in-time capture and efficient changed-block movement, again with nothing installed in guests.
• Linstor/DRBD: a fast changed-block path that respects multi-tenant boundaries — the storage class most backup vendors simply do not support at all.

"Agentless" here is literal: on these paths there is no Universal Client in any guest, no host package per VM, no per-tenant negotiation. The platform integration does the work. Why can most vendors not do this? Because each path is real per-backend engineering against storage internals — there is no platform API to lean on, and a NAS-only design ports nowhere.

Other block storage: the Universal Client — what it does and doesn't

Some CloudStack estates run block storage with no native extent-map or CBT technology to build on. For those, Sendense uses the Universal Client — and it is worth being precise about its job, because it is narrower than the word "agent" usually implies:

• One job: it maintains the changed-block map — Windows guest-side change tracking for storage that cannot provide it. That map is the only thing it contributes.
• Never in the data path: backup data does not flow through the client. Transfer remains snapshot-driven at the hypervisor data layer, exactly as on the native paths.
• Never required on native paths: Linstor/DRBD, ZFS and QCOW2/NFS need no client — ever. The Universal Client exists so that storage without CBT technology behaves like storage that has it.

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 — full image once, changed blocks thereafter. 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.

Incremental forever, into an immutable repository

With change tracking solved, the source is read in full exactly once. Every later job transfers only changed blocks, and 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. Dedup in the repository is also the safety net for any workload captured through a non-native full-read path: repeated runs do not store repeated copies; only new unique data consumes capacity.

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 — Linstor/ZFS/QCOW2-NFS volumes get the agentless CBT paths; anything else is flagged for Universal Client coverage.
• 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.