Guide

Deployment Model

Which Sendense components run where, how they enroll, and how a new deployment comes together.

ReadyCurrentdeploymentshasnatemplate

Deployment Building Blocks

A Sendense deployment is built from a small set of components. Not every deployment uses every component; the mix depends on protected platforms, recovery objectives, provider model, and DR requirements.

SHA

The hub appliance and primary orchestration point for the deployment.

SCA

The central appliance for MSP and CSP management, used where provider-level telemetry, controlled remote access, billing, API, provisioning, or license management is deployed.

SNA

An enrolled node appliance that provides backup proxy capacity, EBA Smart Transport data movement, recovery access, and selected relay paths.

snagent

An optional CloudStack KVM hypervisor host agent for supported host-assisted changed-block tracking.

Sendense Controllers

Recovery-side appliances that act as controller-backed replication targets, one per protected VM.

EBA repositories

Storage targets for backup recovery points, provisioned and managed from SHA.

Sites

Logical locations that group appliances, protected infrastructure, and recovery infrastructure.

Deployment Shapes

Standalone customer SHA

A customer operates SHA without SCA.

MSP-managed customer SHA

SCA sits above customer SHAs for telemetry and controlled remote access. Enrollment into SCA can be customer-led or MSP-led depending on the relationship between MSP and customer.

CSP-provisioned tenant SHA

SCA provisions and enrolls tenant SHA capacity automatically for provider-led billing, API, provisioning, and license management.

SHA remains the hub

SHA remains the hub for each customer or tenant deployment in all three shapes. SCA adds provider capabilities; it does not replace the customer's SHA.

Deployment Sequence

A standalone or customer-SHA deployment follows this high-level order:

Deploy and bootstrap SHA, then configure administrative access, licensing where applicable, sites, and basic platform settings.
Provision at least one EBA repository.
Enroll enough SNAs for the sites or protected environments that need backup proxy capacity, recovery access, load balancing, or fault tolerance.
Configure source infrastructure credentials and discovery.
For supported CloudStack KVM environments, generate and run snagent host-agent installers where host-assisted changed-block tracking is wanted for QCOW NFS, ZFS, or LINSTOR DRBD backends.
Create protection patterns and confirm recovery-point creation.
Create replication patterns where DR replication is required. Sendense Controllers are provisioned through replication patterns.
Validate health, backup, restore, replication, and failover readiness, then establish update, monitoring, support, and maintenance procedures.

Provider deployments

MSP-managed deployments add SHA enrollment into SCA using the customer-led or MSP-led path agreed for that customer. In CSP deployments, SHA provisioning and SCA enrollment are automated provider platform work rather than a manual customer task.

SHA Deployment

SHA is deployed as a supported Sendense virtual appliance or image in the customer or provider environment.

Current packaging includes supported virtual appliance images. More deployment formats may be introduced over time, but the role stays the same: SHA is the hub appliance for the protected environment.

SNA Placement And Scale

SNAs are virtual appliances that enroll with SHA and perform backup proxy work. An SNA can enroll with SHA over the Internet where the deployment design permits it, and it still needs access to the protected or recovery infrastructure for its assigned workflows.

Plan placement around connectivity, throughput, resilience, and proximity to the infrastructure being protected. Customers commonly deploy multiple SNAs for load balancing and fault tolerance.

As an initial planning guide, use roughly one SNA for every five concurrent backup jobs, then refine for workload size, storage performance, network capacity, recovery workflows, and resilience requirements.

Trust And Enrollment

Sendense appliances and agents are enrolled or approved before they participate in workflows.

SNA enrollment is pairing-code based. SHA generates a pairing code, the appliance requests enrollment, and an administrator reviews the pending enrollment, assigns a site, checks the appliance identity and fingerprint, and approves or rejects it. After approval, the appliance reports health and heartbeat.

SHA enrollment into SCA follows the provider model: customer-led or MSP-led for MSP deployments, and automated provider-led provisioning for CSP deployments.

Controller Template

For controller-backed replication, the destination system must have the Sendense Controller template available before Sendense can provision controller VMs. Controllers are created on demand as VMs are added to replication patterns.