CloudRebuild captures the dependency graph of your cloud estate at backup time and restores resources in an order that respects it. Snapshot, manifest, dependency-ordered restore and cross-cloud translation, across Azure, AWS, Google Cloud and Oracle Cloud Infrastructure.
Why restores fail
Copying bytes is the easy part of backup. Restores fail because cloud resources are a graph, not a list: a virtual machine needs its network, its security group, its key vault and its disks to exist first, and to exist in the right relationship. Tools that treat a backup as a bag of independent resources rebuild them in an arbitrary order and discover the problem halfway through recovery.
Topology, frozen at backup, applied at restore
The dependency graph captured at backup time is the only source of truth for restore order. The same recovery point produces the same restore order today, tomorrow and next year, regardless of what the live cloud looks like at the time.
- 12 canonical dependency edge types — including
BOUND_TO,DEPENDS_ON,CONTAINSandMANAGED_BY. - Cycle detection using Tarjan’s strongly-connected-components algorithm, so invalid restore plans are rejected rather than attempted.
- The manifest snapshot is frozen at backup. The live graph is never consulted at restore time.
- Offline DR works even when the source cloud is entirely unavailable.
Worked example — Azure VM restore order
- Virtual Network + Subnet — network foundation must exist before VMs.
- NSG + Key Vault — security dependencies before compute.
- Managed Disks + NIC — storage and network interface.
- Virtual Machine — all dependencies satisfied, so the VM restores last.
Three classes of resource, three backup strategies
Not every cloud resource is worth backing up the same way. CloudRebuild classifies resources and applies the strategy that actually fits.
Configuration-led (config_first)
Resources whose value is their configuration — Azure Data Factory pipelines, linked services, triggers. CloudRebuild captures configuration, structure and secret references. Secrets are rebound by the operator at restore rather than copied.
Data-led (data_first)
Resources whose value is their bytes — ADLS Gen2 filesystems, object stores. CloudRebuild captures the data, minimal configuration, metadata and ACLs. ACL application runs as a separate restore phase after data transfer completes.
Compound
Resources that are both, such as Databricks workspaces. The workspace backup orchestrates child backup jobs through the same pipeline, with configuration-led and data-led sub-resources coordinated — no bespoke code path.
Restore plans are immutable
A restore plan is created once, reviewed and approved. From approval onward the plan does not change: retries create new rows rather than mutating the approved plan. What was reviewed is what executes, and the audit trail shows exactly what ran.
What is protected
| Provider | Compute | Storage | Network | Database | Analytics | Cross-cloud |
|---|---|---|---|---|---|---|
| Azure | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| AWS | ✓ | ✓ | ✓ | ✓ | — | ✓ |
| Google Cloud | ✓ | ✓ | ✓ | ✓ | — | ✓ |
| OCI | ✓ | ✓ | ✓ | — | — | ✓ |
Common questions
How is this different from cloud-native snapshots?
Native snapshots protect individual resources well. They do not record how those resources relate to each other, so rebuilding an environment from them is a manual reconstruction exercise. CloudRebuild stores the topology alongside the data and uses it to drive restore order.
What happens if the dependency graph contains a cycle?
Cycle detection rejects the plan before execution rather than deadlocking partway through a restore.
Can I restore into a different cloud?
Yes — see cross-cloud restore, which uses the same recovery point as input.
Request a demo to see a dependency-ordered restore against your own environment.