Overview
Architecture
A system-level view of the Sendense control plane, backup data path, recovery-point storage, provider management, and DR target architecture.
Architecture Model
Sendense uses a disaggregated architecture. The hub, backup proxy, storage, provider-management, host-assist, and DR target roles are separated so each part can be placed, scaled, updated, and governed for the deployment.
The architecture is built around SHA as the hub appliance. Other components connect to SHA or are coordinated by SHA according to the workflow being run.
Architecture layers
SCA and enrolled SHAs
Provider Overlay
Adds MSP telemetry and delegated remote operations, or CSP tenant provisioning, billing, API, and license workflows.
SHA, SCA where deployed
Control Plane
GUI/API workflows, RBAC, inventory, policy, job tracking, health, telemetry, reporting, lifecycle, and provider overlay.
SNA, EBA-ST, optional snagent
Backup Data Movement
Reads protected workload data, uses qualified native or host-assisted change information where available, and otherwise uses a full-source-read EBA path to return backup streams to SHA.
SNA, EBA-ST, optional snagent
Backup Data Movement
Reads protected workload data, uses qualified native or host-assisted change information where available, and otherwise uses a full-source-read EBA path to return backup streams to SHA.
EBA repositories
Recovery-Point Storage
Stores governed recovery points, deduplicated backup data, repository state, retention, legal hold, and cleanup state.
SHA, EBA, SNA where needed
Recovery Operations
Presents recovery points, coordinates restore workflows, indexes supported recovery data, and moves restored data to targets.
SHA, SCA where deployed
Control Plane
GUI/API workflows, RBAC, inventory, policy, job tracking, health, telemetry, reporting, lifecycle, and provider overlay.
SHA, Sendense Controllers
DR Target Preparation
Maintains controller-backed replication targets and supports test, planned, and live failover workflows.
Operating Models
SHA remains the hub
SCA adds provider-level management where the operating model uses it. It does not replace SHA as the hub appliance for the protected customer or tenant environment.
Control Plane
SHA is the day-to-day orchestration hub. Administrators use SHA for protection, replication, recovery, EBA repository governance, SNA lifecycle, snagent lifecycle for supported CloudStack KVM deployments, health, reports, diagnostics, and entitlement workflows.
SCA is a provider overlay above customer or tenant SHAs. MSP use focuses on telemetry and delegated remote operations. CSP use focuses on tenant provisioning, billing, API, and license-management workflows.
Access to actions is governed by RBAC, edition, readiness gates, and provider access policy. MSP access is delegated. CSP tenant access is provider-defined.
Backup Data Path
Protection patterns define workload scope, schedule, repository choice, retention, validation, and immutability usage. SHA schedules and coordinates the backup job.
SNA performs the backup proxy work. It reads protected workload data and uses EBA Smart Transport to send backup streams back to SHA over the secure data path. EBA stores the resulting recovery point in the selected repository.
For CloudStack KVM QCOW NFS, ZFS, and LINSTOR DRBD host-assisted modes, snagent prepares the source and supplies extent information to SNA; if the required agent path is unavailable, the job can fail. RAW Block does not use snagent and follows the full-source-read EBA path with repository deduplication.
Backup architecture
Policy
Protection Pattern
Defines workload scope, schedule, repository choice, retention, validation, and immutability usage.
Coordinator
SHA
Schedules and supervises the backup job and records recovery-point state.
Backup proxy
SNA + EBA-ST
Reads protected workload data and returns backup streams through the smart transport path.
Optional CloudStack KVM host assist
snagent
Supplies extent-map information when the configured host-assisted backend supports it.
Backup proxy
SNA + EBA-ST
Reads protected workload data and returns backup streams through the smart transport path.
Backup proxy
SNA + EBA-ST
Reads protected workload data and returns backup streams through the smart transport path.
Coordinator
SHA
Schedules and supervises the backup job and records recovery-point state.
Recovery-point storage
EBA Repository
Stores governed recovery points and deduplicated backup data.
Recovery Architecture
EBA recovery points are the starting point for restore, browse, validation, file and item recovery, and full VM restore workflows.
SHA coordinates recovery operations through the GUI and policy model. EBA serves recovery-point data, and SNA participates where data movement or site-side access is required.
Full VM restore and controller-backed DR failover are different recovery paths. A full VM restore creates a recovered workload from an EBA recovery point. Controller-backed DR failover promotes an existing controller-backed target maintained by a replication pattern.
DR Architecture
Replication patterns define which workloads are replicated, where target readiness is maintained, and how controller-backed targets are prepared.
For controller-backed replication, Sendense provisions one Sendense Controller per protected VM after the destination controller template is available. This lets target-side preparation and failover work scale horizontally with the protected workload count.
Replication data moves from the SNA at the protected site to the SNA at the recovery site, and the recovery-site SNA passes it to the Sendense Controller for that VM. The route between the sites is chosen per replication pattern: data can travel through the encrypted appliance connections via SHA, or directly between the two SNAs over the site-to-site network after a live reachability check. SHA orchestrates every sync on either route.
Failover can be test, planned, or live. Planned failover can perform a final sync where configured. During failover, Sendense promotes the controller-backed target, applies destination mappings and guest remediation where applicable, starts the recovered workload, and records recovery state.
DR replication topology
Both replication routes end the same way: the target SNA receives the replication stream and passes it to the Sendense Controller for that VM inside the recovery site.
Route A: Via SHA
Source SNA to SHA to target SNA to Sendense Controller. Replication data travels inside the always-on encrypted appliance connections, so each site only needs its normal outbound connection to SHA.
Route B: Direct P2P
Source SNA directly to target SNA to Sendense Controller. Replication data crosses the site-to-site network after a live reachability probe. In Automatic mode, a failed probe falls back to Route A.
Scale And Resilience
- Multiple SNAs can be enrolled for load balancing and fault tolerance. A practical starting point is about one SNA for every five concurrent backup jobs, adjusted for workload size, storage performance, network capacity, and recovery needs.
- Controller-backed replication uses one Sendense Controller per protected VM.
- EBA repository placement, capacity, retention, immutability, legal hold, and cleanup policy are planned as part of backup architecture.
- SCA can sit above multiple SHAs in MSP and CSP models, but SHA remains the operational hub for each protected environment.
- Not every deployment uses every component. The required architecture depends on protected platforms, recovery objectives, provider model, and DR requirements.
Architecture Boundaries
- SCA is a provider overlay, not a replacement for SHA.
- SNA is the backup proxy; snagent is the CloudStack KVM hypervisor host agent.
- EBA is the backup storage and recovery-point system, not the live DR failover target.
- EBA full VM restore and controller-backed DR failover are separate recovery paths.
- snagent is required for qualified QCOW NFS, ZFS, and LINSTOR DRBD host-assisted modes, but not for every Sendense backup.
- Repository feature coverage can vary by provider and configuration. Immutability, legal hold, and external S3-compatible repository behavior depend on supported and configured capabilities.
Related Docs