CloudStack Backup
Protect CloudStack workloads across qualified hypervisor and storage paths, with recovery points held in the repository you operate.
Explore CloudStack BackupFor Cloud Service Providers
Build backup, DR and migration services on the cloud you control.
Use the infrastructure you already operate to deliver BaaS, DRaaS and migration across CloudStack, VMware, Nutanix AHV and mixed estates. You own the recovery cloud, repositories and customer relationship. Sendense provides the platform that brings it together.
Provider services
What will you build?
Choose the service you want to take to market. Sendense brings protection, recovery and migration together across the customer estates you operate.
Showing Disaster Recovery as a Service
Backup as a Service
Deliver managed backup, retention and recovery across customer estates from infrastructure and repositories you control.
Explore Backup as a Service
Disaster Recovery as a Service
Replicate workloads into your recovery cloud, test recovery and run controlled failover when customers need it.
Explore Disaster Recovery as a Service
VMware Migration
Move customers from VMware to CloudStack with continuous sync, test cutover, rollback and commit.
Explore VMware Migration
Replace Existing Protection
Consolidate fragmented protection tools onto one platform for backup, DR, recovery and mobility.
Explore replacement evaluation
What do you need to evaluate?
Work through the commercial, architecture, operations, service-design and security decisions that shape a provider service.
Business & Commercial
Sendense CSP licensing is designed for providers that operate the platform and deliver backup, DR, migration or hosted protection services.
Commercial scoping starts with your deployment, tenancy, workload and service model, so the licensing route reflects how you intend to operate.
Define workload scope, retention, recovery targets, reporting and support ownership around the service you plan to take to market.
Use a representative first tenant to validate the operating model before wider rollout.
Packaging dimensions
- workload scope
- retention requirement
- recovery target
- service operation
- reporting requirement
- support boundary
Architecture
Start from the environment you operate. Supported CloudStack and mixed estates are qualified by hypervisor, storage path, recovery target and tenancy. CloudStack support is path-specific. Confirm the hypervisor and primary-storage path for the workloads in scope. Dedicated tenant SHA, multi-tenant SHA provider API and SCA fleet control are different patterns.
| Dimension | Qualification question |
|---|---|
| source platform | Which platforms and versions are in scope for the first tenant? |
| hypervisor | Is the CloudStack estate KVM, XCP-ng/XenServer or VMware-backed? |
| storage path | Which primary storage path does each workload use? |
| repository | Where will the provider keep recovery points, and who operates that repository? |
| recovery target | Is recovery back to the same CloudStack zone, another site, or a different platform? |
| backup / DR / migration use case | Is the first-tenant proof backup, replication/DR or a controlled migration? |
| tenant model | Is each customer a dedicated SHA, a site on one multi-tenant SHA, or both? |
| control-plane topology | Does the provider need SCA above tenant appliances, or only SHA automation? |
| connectivity | Which control and data paths are available between SHA, SNA and the CloudStack estate? |
Dedicated or tenant SHA
A CSP may provision a dedicated single-tenant appliance per customer. That SHA remains the hub for that tenant's protection, recovery and repository work. SCA, when used, sits above it and does not replace it.
Multi-tenant SHA provider API
One multi-tenant SHA can host many sites. The published provider API currently covers the documented migration and DR workflow. Backup protection patterns and EBA operations use other product surfaces.
SCA fleet and front door
SCA is a control plane above customer or tenant SHA deployments. Backup data does not pass through it. SCA API work and SHA provider API work are different contracts.
Operations
The SHA holds records and jobs. The provider service owns workflow state, approval, durable identifiers, polling and third-party integration. Sendense does not call the provider back.
Sendense appliance responsibilities
- Tenant, site, user and vault-credential records on the SHA
- Source discovery through node appliances
- Replication patterns, targets, disks and sync jobs
- Failover, rollback and commit orchestration on the appliance
- Licence capacity and consumption reported by the appliance
Provider service and orchestrator responsibilities
- The workflow state machine across those SHA operations
- Business approval before irreversible cutover
- Durable identifiers and idempotency keys
- Polling for job, RPO and readiness state because Sendense does not call back
- CMDB, ITSM, notification and billing integration
site_id authorises. Every tenancy gate resolves against the site that owns the object.
tenant_id groups. It is an organisational and reporting key and never authorises access.
The provider service credential is server-side only, appliance-wide, and must never be placed in a browser, mobile app, tenant system, client-side JavaScript, source repository, ordinary log, screenshot or ticket.
A site API token is not accepted in this provider API profile.
Service Design
Map each service line across product capability, automation, provider operations and commercial scope.
CloudStack backup
- Customer/workload scope
- Named CloudStack hypervisor and storage paths
- Control-plane/topology decision
- SHA plus qualified host-assisted or full-source-read path
- Repository/recovery decision
- Provider-operated repository design
- Operational evidence
- Protection-pattern and repository evidence on the SHA, not this provider API profile
- Commercial scoping
- Workload, retention and support boundary
- Capability split
- Product: Protect qualified CloudStack paths. API: Not currently in the multi-tenant SHA provider API. Provider process: Service catalogue, billing and operator runbooks. Still to scope: Which storage paths are in the first tenant.
BaaS
- Customer/workload scope
- Provider-defined customer sets on supported platforms
- Control-plane/topology decision
- Dedicated tenant SHA, multi-tenant SHA, or mixed
- Repository/recovery decision
- Retention and deletion policy owned by the provider
- Operational evidence
- Recovery points and reporting the provider chooses to expose
- Commercial scoping
- Packaging is the provider's business decision
- Capability split
- Product: Backup on supported platforms where qualified. API: Backup protection patterns are outside the current provider API. Provider process: Tenant onboarding, billing and support. Still to scope: Whether BaaS uses the same appliance as DRaaS.
DRaaS
- Customer/workload scope
- Workloads that need test failover and cutover evidence
- Control-plane/topology decision
- Multi-tenant SHA provider API or dedicated SHA plus operator process
- Repository/recovery decision
- Replica and target design on a supported recovery platform
- Operational evidence
- RPO, readiness, test failover and rollback records
- Commercial scoping
- Recovery target and operator handoff
- Capability split
- Product: Replication, test failover, rollback, cutover and commit on SHA. API: Documented DR/migration workflow on SHA v4.3.600. Provider process: Approval before irreversible commit. Still to scope: Recovery site and tenancy anchor.
VMware-to-CloudStack migration
- Customer/workload scope
- Named VMware estate moving to a qualified CloudStack destination
- Control-plane/topology decision
- SHA replication and cutover; destination CloudStack credentials in the vault
- Repository/recovery decision
- Replica retained until commit
- Operational evidence
- Sync, readiness and cutover journal
- Commercial scoping
- Migration licensing is a separate commercial route
- Capability split
- Product: Controlled cutover; no universal downtime figure. API: Discovery, pattern, sync, test, cutover and commit operations. Provider process: Wave plan and customer change window. Still to scope: Custom CloudStack offerings and keyboard/root requirements.
Hosted protection
- Customer/workload scope
- Provider-hosted protection of customer or internal estates
- Control-plane/topology decision
- Must not collapse SCA, tenant SHA and multi-tenant SHA into one picture
- Repository/recovery decision
- Provider-controlled repository and retention
- Operational evidence
- Whatever the chosen topology can actually emit
- Commercial scoping
- Quoted after topology is understood
- Capability split
- Product: Protection on supported platforms. API: Only the documented SHA workflow when that topology is chosen. Provider process: Tenant boundary and reporting. Still to scope: Which topology the first tenant actually uses.
Security & Assurance
Review how provider credentials, site permissions, platform credentials, audit records, repository controls and recovery validation fit your operating model.
Provider credential handling
The provider service credential is minted by an administrator session, stored server-side and treated as appliance-wide. It is never a tenant or browser secret.
Tenant and site authorisation
site_id authorises object access. tenant_id only groups records. An empty site list means no sites, never all sites.
Role and permission scope
Provider-token permissions are intersected with the minting administrator. Users and RBAC remain an appliance concern.
Credential vault
Platform credentials for CloudStack, VMware or Nutanix are stored and tested in the vault. Destination types are explicit.
Audit trail
Failover and cutover jobs write a journal the provider can inspect. That journal is the documented audit trail for those jobs.
Repository, retention and recovery evidence
Repository retention, deletion and recovery-validation controls exist on the product. Validation evidence shows a recovery point can be used. It is not complete recovery proof and no independent assessment is published here.
Prove the operating model with one representative tenant.
Stage 1
Qualify the environment
Record the platforms, hypervisors, storage paths and connectivity that the first tenant will exercise.
Stage 2
Choose the exact topology and supported use case
Select dedicated tenant SHA, multi-tenant SHA provider API or SCA-fronted topology for that tenant and keep those patterns distinct.
Stage 3
Select representative workloads
Choose workloads that exercise the intended storage path and recovery target.
Stage 4
Define technical and operational success criteria
Agree compatibility, ownership, connectivity, protection or sync, recovery, tenant boundary and operator handoff before the run.
Stage 5
Run the supported protection, replication or migration workflow
Run the workflow the chosen topology actually supports, and keep backup protection-pattern operations on the product surfaces that own them.
Stage 6
Inspect recovery, readiness and operational evidence
Read RPO, readiness, test-failover or backup evidence that the chosen path can produce.
Stage 7
Review commercial fit before broader rollout
Scope licensing after the deployment, tenancy and service model are understood.
Success criteria
- compatibility
- deployment ownership
- connectivity
- initial protection or sync
- incremental operation where supported
- recovery/test workflow
- tenant boundary
- monitoring and evidence
- operator handoff
- commercial scope
Evidence
Explore the architecture, compatibility, security, provider API and product documentation behind the service model. The Quadris customer story shows Sendense in a VMware-to-CloudStack migration project.
Bring the environment, service model and first-tenant use case.
Bring your environment, service model and first-tenant use case. We will map the architecture, operating responsibilities, evaluation plan and licensing route.
Cloud Service Provider FAQs
Is the CSP relationship a customer or partner model?
A Cloud Service Provider licences and operates Sendense as a customer. MSP resale is a separate commercial model.
What does the current provider API automate?
On Sendense SHA v4.3.600 the multi-tenant SHA provider API automates provider credential management, tenant, site and user onboarding, platform credential provisioning, source discovery, replication patterns, initial and incremental sync, RPO and readiness polling, test failover and rollback, planned and unplanned cutover, commit, licence and health monitoring, error and retry handling, and offboarding, subject to permissions and prerequisites.
Does the current provider API include backup and EBA operations?
No. The published provider API currently covers the documented migration and DR workflow. Backup protection patterns and EBA operations use other product surfaces. Do not treat the current provider API as a complete multi-tenant BaaS API.
What environment information is needed before a first-tenant evaluation?
Platforms, hypervisors, storage paths, recovery target, tenant model, control-plane topology, connectivity, the exact use case and the operator who will own workflow state. Licensing is scoped after that operating model is understood.
How must the provider service credential be handled?
It is a server-side, appliance-wide credential. It must never be placed in a browser, mobile app, tenant system, client-side JavaScript, source repository, ordinary log, screenshot or ticket. A site API token is not accepted in this profile.
Who owns workflow state and third-party orchestration?
The provider's external service owns the workflow state machine, business approval, durable identifiers, polling, and CMDB, ITSM, notification or billing integration. Sendense exposes state and identifiers. It does not call the provider back and does not host webhooks or an OAuth workflow engine for this path.