CloudStack backup
Protect hosted workloads across qualified CloudStack hypervisor and storage paths, with recovery points held in the repository you operate.
Explore backupFor Cloud Service Providers
Build migration, backup and disaster recovery services on Apache CloudStack.
Use one Sendense control plane to move VMware workloads into CloudStack, protect the workloads you already host and deliver profitable BaaS and DRaaS services on infrastructure you control.
Supported platforms
Migration, protection and recovery paths across the platforms your customers run today.
Supported today
- CloudStack
- VMware
- Nutanix AHV
- Azure
- OSSEA
Service opportunities
Turn CloudStack capability into services customers will buy.
Sendense joins migration and ongoing protection so the commercial relationship continues after a workload reaches your cloud.
Showing VMware migration
Backup as a Service
Package managed backup, retention and recovery using repositories you operate.
Design a BaaS offer
VMware migration
Migrate VMware workloads to CloudStack with continuous sync, test cutover, rollback and commit.
Explore migration
Disaster Recovery as a Service
Deliver replication, recovery testing and controlled failover into your recovery cloud.
Design a DRaaS offer
CloudStack-aware protection
Built around the cloud you actually operate.
Sendense carries CloudStack context across backup, replication and recovery. Protection is qualified against the hypervisor, storage path, target and tenancy model instead of assuming every provider runs the same architecture.
Hypervisors
- KVM
- XCP-ng and XenServer
- VMware vSphere
Storage and repositories
- Mixed storage estates
- Provider-controlled repositories
Services
- CloudStack backup
- Migration
- Backup as a Service (BaaS)
- Disaster Recovery as a Service (DRaaS)
Your recovery cloud, repositories and customer relationship remain under your control.
Keep migration projects moving
VMware to CloudStack without VDDK.
Sendense does not use VMware’s Virtual Disk Development Kit and is unaffected by Broadcom’s withdrawal of VDDK from public download. CSPs can continue VMware-to-CloudStack migration projects today, then protect the migrated workloads through the same Sendense platform.
Synchronise and test
Replicate VMware workloads into KVM-backed CloudStack while production runs, then test boot, networking and application acceptance on the target.
Cut over
Run the final synchronisation and make the production change only when the exit checks pass, keeping a return point until commit.
Continue protection
Enrol the migrated workloads in backup, retention and recovery on the same Sendense platform.
Synchronise, test, cut over and continue protection without assembling separate migration and backup toolchains.
Customer evidence — Quadris
A VMware estate moved into protected CloudStack.
Quadris used Sendense to migrate a complete VMware estate into its Apache CloudStack-based cloud inside the customer’s deadline, followed by ongoing Backup as a Service through the same platform.
Under one hour
Deployment to replication.
14 days
Complete VMware estate migrated.
Ongoing BaaS
Backup as a Service after migration, through the same platform.
Results from one customer project. Migration timelines vary according to estate size, connectivity, workload dependencies and cutover requirements.
CloudStack assessment
Request a CloudStack migration and protection assessment.
Tell us about the VMware source, CloudStack platform and service you want to deliver. We’ll map the migration path, destination requirements and ongoing protection model with you.
Source and destination
Review the VMware source and the CloudStack destination.
First use case
Identify the first migration or protection use case.
Service requirements
Map backup, DR and provider-service requirements.
Next step
Agree the practical next step or pilot.
The request opens on our technical request form. Choose Architecture Session and tick the areas you want to cover: VM Migration, Backup, Disaster Recovery or Managed Service / BaaS / DRaaS.
In the environment details, tell us whether you operate CloudStack today, are deploying it or are evaluating it, with anything else that helps: approximate workload count, CloudStack version, hypervisor, primary storage, project timeframe and your migration or protection requirements.
Go deeper when you are ready.
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
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.
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.
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.
Does Sendense use VDDK for VMware-to-CloudStack migration?
No. Sendense does not use VMware’s Virtual Disk Development Kit (VDDK) and is unaffected by Broadcom’s withdrawal of VDDK from public download. VMware-to-CloudStack migration projects can proceed with Sendense today, and the migrated workloads can then be protected through the same Sendense platform.
FInd out more.
Tell us more about your CloudStack environment and service model interest and we will map the Sendense architecture, evaluation plan and licensing model.