Backup & Disaster Recovery

Backup and disaster recovery for enterprise cloud

Designed for resilience, governed by clear recovery objectives

Backup and disaster recovery are core elements of enterprise risk management. Effective strategies are defined by explicit recovery objectives, architectural decisions, and operational discipline — not by default platform promises.

whitesky provides the building blocks to design and operate enterprise-grade backup and disaster recovery architectures while keeping control with the organization.

Backup and disaster recovery as architectural decisions

Enterprises approach data protection differently depending on:

  • business criticality
  • regulatory requirements
  • acceptable recovery time (RTO)
  • acceptable data loss (RPO)

whitesky does not impose a single model. Instead, it enables enterprises to design backup and recovery strategies that align with their risk profile.

Built-in backup capabilities

whitesky provides integrated mechanisms to protect workloads at platform level, including:

  • patent-pending, block-level incremental backups of virtual machines to S3-compatible storage (how it works)
  • storage-level consistency where applicable
  • retention policies aligned with enterprise requirements
  • backup data stored separately from primary workloads

These capabilities provide a foundation for operational backup without requiring external tooling.

Separation of failure domains

Effective recovery requires separation.

whitesky supports separation across:

  • compute and storage resources
  • availability zones or server blocks
  • physical locations
  • administrative and operational access

This reduces correlated failures and supports resilient designs.

Disaster recovery across locations

For enterprises requiring higher resilience, whitesky supports multi-location recovery architectures:

  • secondary sites for disaster recovery
  • controlled replication strategies (third-party replication today, native on the roadmap)
  • planned failover and failback procedures
  • alignment with defined RPO and RTO targets

Location selection and topology remain enterprise decisions.

Virtual machine replication across sites

Disaster recovery designs often require replicating virtual machines between sites to reduce recovery time and operational complexity. whitesky supports replication-based approaches that align with enterprise RPO/RTO objectives and multi-location architectures.

Supported options today (third-party replication)

Today, the most supported approach for virtual machine replication uses third-party replication tooling such as Mobiti and RackWare.

These tools can be used to replicate virtual machines:

  • between whitesky cloud locations, and/or
  • between whitesky and other virtualization platforms

This enables controlled cutover and failover strategies where workloads can be brought online in a secondary site with minimal downtime, depending on application coordination and replication policy.

Roadmap: native asynchronous VM replication

whitesky is planning to add native asynchronous virtual machine replication across sites. The intent is to provide a platform-level replication capability that reduces external dependencies while keeping replication policy and governance under enterprise control.

Disaster recovery across locationsVMs in a primary location are replicated to replica VMs in a secondary site for disaster recovery: today with third-party tooling such as Mobiti or RackWare, with native asynchronous replication on the roadmap. Failover and failback are planned procedures. Locations, topology and the RPO and RTO targets remain enterprise decisions.Primary locationproduction workloadsVMVMVMVMSecondary sitefor disaster recoveryreplicareplicareplicareplicaVM replicationtoday: Mobiti or RackWareroadmap: native asyncfailover / failbackplanned proceduresYour decisions: locations, topology, RPO and RTO targetsRPO: acceptable data loss · RTO: acceptable recovery time
Disaster recovery across locationsVMs in a primary location are replicated to replica VMs in a secondary site for disaster recovery: today with third-party tooling such as Mobiti or RackWare, with native asynchronous replication on the roadmap. Failover and failback are planned procedures. Locations, topology and the RPO and RTO targets remain enterprise decisions.Primary locationproduction workloadsVMVMVMVMVM replicationtoday: Mobiti or RackWareNative async replicationroadmapPlanned failoverand failbackSecondary sitefor disaster recoveryreplicareplicareplicareplicaYour decisions: locations,topology, RPO and RTO targetsRPO: acceptable data lossRTO: acceptable recovery time
VM replication to a secondary site: third-party tooling today, native asynchronous replication on the roadmap.

Roadmap: geo-redundant cloud locations

In addition to asynchronous replication, whitesky is planning geo-redundant cloud locations designed to span multiple datacenters.

The goal is a deployment model similar to “regions” in hyperscaler terminology, where:

  • a single cloud location spans multiple datacenters, and
  • data is synchronously replicated between those datacenters

This includes synchronous replication of both:

  • block data, and
  • object data

This model is intended to reduce correlated failure risk and simplify high-availability designs for enterprise workloads, while preserving locality and operational control.

From replication across locations to geo-redundant locationsToday, VMs are replicated asynchronously between two cloud locations, with third-party tooling and native replication on the roadmap. On the roadmap, a geo-redundant cloud location spans two datacenters and replicates block and object data synchronously between them, like a hyperscaler region, to reduce correlated failures and simplify high availability.Today: across locationsLocation AVMsLocation BVMsasynchronous VM replicationthird-party today, native on roadmaptwo cloud locationsRoadmap: geo-redundant locationOne cloud locationDatacenter 1blockobjectDatacenter 2blockobjectsynchronous replication ofblock and object dataGoal: like hyperscaler "regions", with fewer correlated failures and simpler high availability
From replication across locations to geo-redundant locationsToday, VMs are replicated asynchronously between two cloud locations, with third-party tooling and native replication on the roadmap. On the roadmap, a geo-redundant cloud location spans two datacenters and replicates block and object data synchronously between them, like a hyperscaler region, to reduce correlated failures and simplify high availability.Today: across locationsLocation AVMsLocation BVMsasynchronous VM replicationthird-party today, native on roadmaptwo cloud locationsRoadmap: geo-redundant locationOne cloud locationDatacenter 1blockobjectDatacenter 2blockobjectsynchronous replication ofblock and object dataGoal: like hyperscaler "regions", withfewer correlated failures, simpler HA
Roadmap: one cloud location spanning two datacenters, with block and object data replicated synchronously.

Integration with enterprise backup strategies

whitesky does not expose the hypervisor layer to third-party agentless backup software. This is a deliberate architectural choice to maintain strong isolation, predictable operations, and platform integrity.

Enterprises can integrate backup strategies in the following supported ways:

Built-in platform backups

whitesky provides platform-level backup mechanisms, including block-level incremental backups of virtual machines and storage-level separation between primary workloads and backup data.

These capabilities form the baseline for operational backup and recovery.

Agent-based backups inside the workload

Enterprises can deploy backup agents inside virtual machines where required by policy or tooling standards.

This approach:

  • keeps backup logic within the workload security boundary
  • avoids privileged access to the virtualization layer
  • aligns with strict isolation and compliance requirements

Recovery media-based restore workflows

Existing enterprise backup solutions that support recovery media (bootable restore environments, tested with VMware, Veeam and Acronis) can be used to restore systems into whitesky-managed virtual machines.

This enables:

  • reuse of existing backup repositories
  • controlled restore procedures
  • gradual migration or coexistence strategies

This model avoids hidden dependencies between the cloud platform and external backup software, and ensures that backup and recovery processes remain explainable, testable, and auditable.

Supported ways to integrate enterprise backupThree supported ways to back up workloads on whitesky: built-in snapshot backups at platform level, stored separately from primary data; a backup agent from your own backup software running inside the virtual machine; and restoring from an existing backup repository by booting recovery media in an empty VM. Agentless backup software gets no access to the whitesky hypervisor layer.Your backupsoftwareVirtual machinebackupagent2workloadwhitesky hypervisor layerno agentless accessto the hypervisor1Built-in snapshot backupsseparate from primary dataExisting backuprepository3recovery media bootsan empty VM, thenrestores into it1Built-in platform backups2Agent inside the VM3Recovery-media restore
Supported ways to integrate enterprise backupThree supported ways to back up workloads on whitesky: built-in snapshot backups at platform level, stored separately from primary data; a backup agent from your own backup software running inside the virtual machine; and restoring from an existing backup repository by booting recovery media in an empty VM. Agentless backup software gets no access to the whitesky hypervisor layer.Your backupsoftwareExisting backuprepositoryVirtual machinebackupagent2workload3restorewhitesky hypervisor layer1Built-in snapshot backupsseparate from primary data✕No agentless backup accessto the hypervisor layer1Built-in platform backups2Agent inside the VM3Recovery media boots an empty VM
Three supported ways to integrate backup, and one deliberate no: agentless backup software gets no access to the hypervisor layer.

Testing, validation, and auditability

Backup strategies are only effective if they are tested.

whitesky enables:

  • controlled restore testing
  • validation of recovery procedures
  • documentation of backup and recovery workflows
  • auditability for internal and external reviews

Recovery processes remain observable and verifiable.

Operational clarity and responsibility

As with other aspects of the platform, responsibilities are explicit:

  • whitesky

    • provides and operates platform-level backup capabilities
    • maintains infrastructure reliability
    • ensures platform lifecycle consistency

  • Enterprise IT

    • defines backup policies and retention
    • selects recovery architectures
    • validates recovery procedures
    • governs compliance and risk acceptance

This clarity is essential for governance and audits.

Avoiding false assurances

Enterprise resilience is not achieved through abstract guarantees.

whitesky avoids:

  • opaque “always-on” claims
  • hidden dependencies
  • recovery models that cannot be explained or tested

Instead, resilience is designed, documented, and operated consciously.

Delivery model: managed service

whitesky is delivered as a managed service, ensuring consistent operation of backup and recovery capabilities.

A software edition for self-operation is planned, at the earliest in 2027.

Why enterprises use whitesky for backup and recovery

  • explicit control over recovery objectives
  • separation of failure domains
  • multi-location recovery support
  • replication options across sites (third-party today, native roadmap)
  • compatibility with existing backup strategies
  • audit-friendly and explainable designs

Next steps

  • Define or review your RPO and RTO requirements
  • Identify candidate workloads for multi-location protection
  • Design a backup and disaster recovery blueprint with whitesky