Reference
CloudStack Storage Backends
Canonical storage coverage for CloudStack backup across KVM, XCP-ng, XenServer, VMware and mixed primary storage estates.
Short Answer
Sendense protects CloudStack workloads across the named supported hypervisor and storage combinations. The protection plan records the qualified data path for each workload.
Qualified native or host-assisted changed-block paths are used where available. Storage paths without a qualified change map use a full-source-read EBA path; repository deduplication can reduce retained data. Eligible RAW Block protection patterns on version-aware EBA repositories can use Sendense CBT while still performing the full source read; suitable later recovery points can be represented as synthetic incrementals when eligibility and integrity checks pass.
The supported estate includes KVM, XCP-ng, XenServer, VMware-backed CloudStack and the storage paths commonly found in service-provider clouds.
Do not position this as NFS-only
CloudStack storage diversity is the design point. Ceph RBD, raw block, XCP-ng storage repositories, iSCSI, Fibre Channel, StorPool, PowerFlex and VMware storage are named targets, not edge cases.
Supported CloudStack Hypervisors
Named Storage Backends
- Ceph RBD: CloudStack-aware full-source-read EBA path where native changed-block information is not exposed.
- RAW Block: full-source-read EBA path. Eligible protection patterns on version-aware EBA repositories can use Sendense CBT for synthetic-incremental storage. The first and explicitly forced fulls remain genuine fulls; suitable later recovery points are represented as synthetic incrementals only when eligibility and integrity checks pass.
- CLVM and CLVM_NG: qualified native path where available; otherwise the full-source-read EBA path.
- NFS and QCOW2 on NFS: qualified host-assisted changed-block path through snagent where available.
- SharedMountPoint and local storage: full-source-read EBA path where native maps are not exposed.
- iSCSI and Fibre Channel: CloudStack-aware full-source-read EBA path.
- Linstor and DRBD: qualified host-assisted changed-block path through snagent where available.
- ZFS: qualified host-assisted changed-block path through snagent where available.
- PowerFlex / ScaleIO, StorPool and SolidFire: CloudStack-aware full-source-read EBA path.
- VMFS, vSAN, vVols and DatastoreCluster: CloudStack and VMware-aware storage workflows.
- XCP-ng storage repositories: CloudStack-aware full-source-read EBA path.
How The Data Path Is Selected
Sendense first discovers CloudStack zones, hosts, tenants, VMs, volumes and storage placement through scoped CloudStack credentials.
The protection path uses a qualified native storage path where available, optional snagent host assist on supported CloudStack KVM storage paths, or a full-source-read EBA path where no native changed-block map exists.
Backup data lands in EBA repositories where deduplication, compression, retention and restore behavior are governed by Sendense rather than by the primary storage backend.
Relationship To The CloudStack B&R Framework
Sendense does not depend on the CloudStack Backup and Recovery Framework.
The B&R Framework is a provider-plugin orchestration surface. Sendense owns the backup data path with SNA, EBA Smart Transport and EBA repositories.
Use the B&R Framework position page when comparing Sendense with products that market CloudStack UI backup buttons as the support boundary.
Related Docs