CloudRebuild is a unified multi-cloud backup and disaster recovery platform. It protects workloads across Microsoft Azure, Amazon Web Services, Google Cloud Platform and Oracle Cloud Infrastructure, alongside SaaS data in Microsoft 365, Google Workspace and Microsoft Intune — from a single interface, with restore into any supported cloud.
The problem we set out to solve
Most organisations now run on more than one cloud, but backup tooling never caught up. Teams end up operating AWS Backup, Azure Backup, GCP snapshots, Microsoft 365 retention and Google Workspace Vault side by side — five interfaces, five policy models, five ways for a restore to fail.
Worse, cloud-native backup keeps data inside the cloud that created it. When the requirement is to recover somewhere else — because a region is down, a provider contract ended, or a migration is underway — that data is effectively trapped.
What we built
CloudRebuild treats a backup as a portable description of a workload rather than a provider-specific snapshot. Because recovery points are stored in a provider-neutral form, a workload captured in Azure can be rebuilt in AWS, and the platform translates the IAM, networking and storage constructs that differ between providers.
Restores are ordered, not parallel guesswork. CloudRebuild discovers resources, builds a dependency graph, and applies topological sorting so that networks exist before the machines attached to them and identities exist before the resources that reference them.
How the platform is put together
Cloud infrastructure backup and SaaS backup run as separate engines with isolated API servers, worker pools, queue namespaces and database schemas. A problem in one cannot consume the other’s capacity or reach its data.
Our engineering principles
- Recovery is the product. A backup that has never been restored is an assumption, not a safeguard.
- No lock-in. If data cannot leave, it is not protected — it is hostage.
- Dependencies are the hard part. Copying bytes is straightforward; restoring relationships correctly is where recovery actually fails.
- Isolation by default. Separate engines, separate runtimes, separate schemas.
Talk to us
If you are evaluating multi-cloud backup or planning a cross-cloud disaster recovery strategy, get in touch and we will walk you through the platform against your actual environment.