Concept
Sendense and the CloudStack B&R Framework
Why Sendense does not depend on the CloudStack Backup and Recovery Framework for CloudStack protection.
Short Answer
Sendense does not require the Apache CloudStack Backup and Recovery Framework. That is an intentional architecture choice.
The CloudStack B&R Framework is a provider-plugin orchestration surface. It can expose backup actions through CloudStack UI and API workflows for selected providers, but it is not a universal changed-block data path across every CloudStack hypervisor and storage backend.
Sendense protects CloudStack through its own CloudStack-aware protection plane: SNA backup proxies, Sendense CBT, EBA Smart Transport, EBA repositories, optional snagent host assist where applicable, and Sendense recovery workflows.
Do not use framework membership as the support test
B&R Framework integration is not the measure of Sendense CloudStack support. The support model is based on the Sendense data path and CloudStack-aware storage handling, not on whether CloudStack can surface a provider plugin button.
Why Sendense Is Independent
The framework abstracts provider operations; it does not solve changed-block tracking for every CloudStack storage backend.
Service provider estates often mix KVM, XCP-ng, XenServer, VMware-backed CloudStack, Ceph RBD, raw block, NFS/QCOW2, ZFS, Linstor/DRBD, iSCSI, Fibre Channel and provider-specific storage. Those storage paths do not all expose the same native change map.
Sendense keeps changed-block tracking, source-side transfer decisions, repository deduplication, validation evidence, restore behavior and retention governance inside Sendense, where they can be consistent across mixed CloudStack estates.
Framework Plugin vs Sendense Protection Plane
What Sendense Uses Instead
- CloudStack API discovery for zones, hosts, tenants, VMs, volumes and storage placement.
- CloudStack-aware volume handling for protected workload operations.
- SNA appliances as backup proxies and EBA Smart Transport endpoints.
- Native changed-block paths where a storage path provides one.
- Sendense CBT where the CloudStack storage backend does not expose a native changed-block map.
- Optional snagent host assist for supported CloudStack KVM storage paths where it improves read efficiency.
- EBA repositories for deduplicated, compressed, governed recovery points.
- Sendense restore, validation, migration and DR workflows above the stored recovery points.
How To Position It
Use this language when comparing Sendense with CloudStack B&R Framework providers:
- Sendense does not depend on the CloudStack B&R Framework.
- The B&R Framework is a plugin orchestration surface; Sendense owns the backup data path.
- Sendense CBT and EBA Smart Transport are not provided by CloudStack B&R. They are Sendense capabilities.
- CloudStack UI backup buttons are not the same as storage-independent CBT, EBA repository efficiency, recovery evidence or cross-storage recovery behavior.
- For service providers, the important question is whether the platform protects the real storage estate, not whether it appears in the standard CloudStack B&R provider list.
Official CloudStack Documentation Context
Apache CloudStack documents the B&R Framework as a plugin model for third-party backup providers and lists specific supported provider paths in its documentation.
That provider list is useful context for CloudStack plugin workflows, but it does not define the full universe of CloudStack backup architectures. Sendense is deliberately outside that dependency path.
Related Docs