Reference

CloudStack Storage Backends

Canonical storage coverage for CloudStack backup across KVM, XCP-ng, XenServer, VMware and mixed primary storage estates.

ReadyCurrentcloudstackstoragesendense-cbteba-sthypervisors

Short Answer

Sendense protects CloudStack workloads across CloudStack-supported hypervisors and storage backends. Support is not limited to one KVM storage backend or to a CloudStack B&R Framework provider plugin.

Native changed-block paths are used where the storage path exposes them. Sendense CBT, EBA Smart Transport and synthetic incrementals cover storage paths without native change maps.

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

KVM

Supported. Native or host-assisted optimisation is used where available; Sendense CBT is used where the storage path does not expose a native change map.

XCP-ng and XenServer

Supported through the Sendense CloudStack operating model, with Sendense CBT and EBA Smart Transport for storage paths without native changed-block information.

VMware-backed CloudStack

Supported through CloudStack and VMware-aware workflows, with Sendense recovery, EBA retention and mobility features available above the backup data path.

Other CloudStack-supported hypervisors

Supported through the same Sendense CloudStack operating model for CloudStack-supported workload and storage paths.

Named Storage Backends

Ceph RBD: Sendense CBT plus EBA Smart Transport where native changed-block information is not exposed.
Raw block: Sendense CBT plus EBA Smart Transport.
CLVM and CLVM_NG: Sendense CBT or native paths where available.
NFS and QCOW2 on NFS: native CBT-enabled path where available.
SharedMountPoint and local storage: Sendense CBT plus EBA Smart Transport where native maps are not exposed.
iSCSI and Fibre Channel: Sendense CBT plus EBA Smart Transport.
Linstor and DRBD: native CBT-enabled path where available.
ZFS: native CBT-enabled path where available.
PowerFlex / ScaleIO, StorPool and SolidFire: Sendense CBT plus EBA Smart Transport.
VMFS, vSAN, vVols and DatastoreCluster: CloudStack and VMware-aware storage workflows.
XCP-ng storage repositories: Sendense CBT plus EBA Smart Transport.

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 then selects the most efficient available changed-block source: native storage path where available, optional snagent host assist for supported CloudStack KVM storage paths, or Sendense CBT for storage without native changed-block maps.

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, Sendense CBT, 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.