Apache CloudStack Storage and Backup: KVM, Ceph, NFS, Raw Block and Other Data Paths

What storage means in an Apache CloudStack environment

Apache CloudStack does not store workload data itself. It orchestrates hypervisors and storage, and records which volumes belong to which virtual machine, tenant and zone. For backup, the hypervisor and storage backend together decide how a volume can be read, and CloudStack holds the context a backup service needs to protect and restore that volume correctly.

Primary vs secondary storage in CloudStack

CloudStack separates storage into two roles:

• Primary storage holds the disk volumes of virtual machines: their root and data disks. It is attached to a cluster or to a whole zone, and it is where Ceph RBD, NFS, iSCSI, Fibre Channel, local disks and the other backends in the Sendense matrix sit.
• Secondary storage holds templates, ISO images and volume snapshots. It is shared across a zone, usually on NFS or object storage.

Backup is a question about primary storage. The volumes you need to recover live there, so the Sendense compatibility matrix is organised by primary storage backend. Sendense keeps its backup data in its own repository path, where EBA handles deduplication, compression and retention. Secondary storage is not listed in the matrix as a protection source.

Hypervisor and storage path considerations

Sendense supports CloudStack estates running KVM, XCP-ng or XenServer, and VMware vSphere. For each workload it selects one of these data paths, based on the hypervisor and the storage backend:

• Qualified native path. A storage-level change-tracking route that Sendense has qualified. The matrix lists it for CLVM / CLVM_NG, with a full-source read as the alternative.
• Qualified snagent host-assisted changed-block path. snagent, the Sendense host-assist component for KVM, provides changed-block tracking for QCOW2 on NFS, ZFS and Linstor/DRBD.
• CloudStack-aware full-source read with EBA. Used where no qualified change map exists, including Ceph RBD, raw block, iSCSI, Fibre Channel, local storage and XCP-ng storage repositories. Every backup scans and reads the full source; EBA Smart Transport and repository deduplication keep the retained data efficient.
• CloudStack and VMware storage workflow. Used for VMware-backed CloudStack storage on VMFS, vSAN, vVols and datastore clusters.

Faster paths reduce the data read from the source. They do not change what is supported: every backend in the matrix is protected through the same Sendense operating model.

KVM-backed environments

On KVM, the storage backend decides which data path applies. Before commissioning, record for each cluster:

• the primary storage backend and volume format, for example QCOW2 on NFS or raw block;
• whether the selected path needs snagent: QCOW2 on NFS, ZFS and Linstor/DRBD do, raw block does not;
• the network and access prerequisites in the access checklist below.

Where a host-assisted mode is used, snagent must be healthy and correctly placed. If it is unavailable, that protection mode can fail.

Ceph

Ceph RBD is a named Sendense target. Without a qualified native or host-assisted change map, Sendense scans and reads the full source on each backup, through CloudStack-managed volume operations, while EBA deduplicates the retained data in the repository. For capacity planning, that means repository growth is reduced by deduplication, but the read load on the Ceph cluster still reflects the full size of the protected volumes.

NFS

For QCOW2 volumes on NFS primary storage, Sendense uses a qualified snagent host-assisted changed-block path, so incremental backups read changed blocks instead of the whole volume. The path depends on snagent being deployed and healthy on the relevant KVM hosts.

NFS is also commonly used for CloudStack secondary storage. That is a separate role, and it is not what the matrix row describes.

Raw block storage

Raw block volumes are protected through a CloudStack-aware full-source read with EBA repository deduplication, and they do not use snagent. On version-aware EBA repositories, eligible raw block protection patterns can use Sendense CBT: the source is still scanned and read in full, the first and any explicitly forced full backups remain genuine fulls, and suitable later recovery points can be stored as synthetic incrementals when eligibility and integrity checks pass.

ZFS, Linstor and other supported paths

ZFS and Linstor/DRBD use the same qualified snagent host-assisted changed-block path as QCOW2 on NFS. The other backends in the matrix are:

• CLVM / CLVM_NG: a qualified native path or a full-source read.
• SharedMountPoint, local storage, iSCSI, Fibre Channel, PowerFlex / ScaleIO, StorPool and SolidFire / managed primary storage: a CloudStack-aware full-source read with EBA.
• XCP-ng storage repositories: a CloudStack-aware full-source read with EBA, using CloudStack-managed volume operations for the SR-backed volume.
• VMFS / vSAN / vVols and DatastoreCluster: the CloudStack and VMware storage workflow.

For how changed-block tracking works on the host-assisted paths, see how to back up CloudStack with host-assisted CBT.

What the backup platform needs to access

Sendense works through CloudStack-aware volume operations rather than inside the guest, so backup data does not move through software in the protected VM. Commissioning needs:

• a dedicated CloudStack API user with the required role permissions for VM, volume, snapshot, restore and recovery operations;
• snagent only where a supported KVM storage path needs host assist;
• outbound TCP 443 from the relevant Sendense appliances or host-assist components to the SHA, and TCP 8888 between KVM hosts only where snagent peer coordination is deployed;
• the Sendense Controller Template, a DHCP network and the offerings used by replication and restore workflows;
• the STYPE custom OS type on Sendense appliances hosted in CloudStack, where the deployment model requires it.

How to confirm your environment is supported

Use the CloudStack storage and hypervisor compatibility matrix during discovery:

• identify the hypervisor and the primary storage backend for each cluster or zone;
• find the matching row and note the selected Sendense path;
• record any CloudStack, host-assist or network prerequisites in the deployment plan before commissioning.

If a combination is not in the matrix, or you are unsure which row applies, ask for a compatibility review. Sendense confirms the protection path, prerequisites and commissioning plan for each part of the estate.

Next step: CloudStack backup and architecture

To see how these data paths become a backup, recovery and DR service, read about Apache CloudStack backup, recovery and DR. For the API scope, discovery and recovery workflow, see the CloudStack integration architecture, and for why Sendense does not rely on the CloudStack Backup and Recovery Framework, see CloudStack B&R Framework. Cloud service providers can map all of this to tenants and service tiers in the Cloud Service Provider journey.