Rebuild everything. In order.
Most tools stop at "your data is safe." Cloud Parity backs up the entire environment around your data - network, identity, secrets wiring, AKS workloads - and restores it in dependency order, so what comes back isn't files. It's your application, serving.
What your current backups miss
When a region goes down, your VM snapshots come back to a subscription with no network, no identities, no Key Vault wiring, and no cluster to run in. The environment itself was never backed up - until now.
| Capability | Traditional backup tools | Cloud Parity |
|---|---|---|
| VM disks & snapshots | ✓Working today | ◐Building - not shipped |
| Storage backup & restore | ✓Working today | ◐Building - not shipped |
| PostgreSQL backup, restore & content verification | ✓Working today | ✓Working today |
| Kubernetes objects (Deployments, StatefulSets, RBAC…) | -Not covered | ✓Working today |
| Azure resource configs (VNets, subnets, databases, load balancers) | -Not covered | ✓Working today |
| IAM role assignments & managed identities | -Not covered | ✓Working today |
| Key Vault structure & access model | -Not covered | ✓Working today |
| Secret values replicated into a recovery vault | -Not covered | ◐Building - not shipped |
| Dependency-ordered restore into an isolated subscription | -Not covered | ◐Building - not shipped |
| Scheduled restore testing with reports | -Not covered | ◐Building - not shipped |
✓ working today · ◐ building · - not covered
We are in early access and this table says which is which.What works today, and what doesn’tgoes through every line of it.
How it works
BACKUP
Cloud Parity scans everything you run - and every Kubernetes object inside your clusters.
All of it is saved as one restorable backup, updated as your environment changes.
The region fails, or ransomware takes the subscription. Your backup is sealed and safe - press the button.
Rebuilding everything in your recovery region - in dependency order, wired as it was.
DNS flips to the recovery region.
You are serving customers again.
Order is the hard part
Anyone can put resources back. Putting them back in an order that actually starts is the difference between a restore and a recovery.
What gets protected
Your data, and the environment it needs to run. Storage, databases, and disks replicate straight into your recovery subscription - alongside the configuration layer that turns them back into a running application.
Networking
VNets, subnets, NSGs, load balancers, ingress
Data services
Databases, storage accounts, and their contents - replicated directly into your recovery subscription
Identity & access
Role assignments, custom roles, managed identities, and workload identity federation - the permissions layer no VM backup even sees
Key Vault
Vault structure, access model, and secrets available in DR - without Cloud Parity ever reading a value
Compute & applications
AKS, App Service, Function Apps - the platforms your code runs on, with their settings, identities, and scaling rules
Inside Kubernetes
Not just the AKS cluster - the Deployments, StatefulSets, Services, ConfigMaps, Secrets, and RBAC bindings running inside it. Workloads come back, not just the control plane
The connections
The wiring between all of the above - the part that turns resources back into a running system
A backup you haven’t restored is a guess
Restoring is not the test. Checking what came back is. Cloud Parity restores a database and then compares it against the source by row count and a per-table content checksum - because a right count with a wrong checksum is the corruption that counting cannot see.
That runs today, in one command, and we will run it in front of you. Putting it on a nightly schedule and handing you the report ison the list, not in the product.
Questions we get
- Do you need access to our secret values?
- No. Your rows and secret values never leave your subscription - database contents are written inside it, and secrets are replicated vault-to-vault inside your own tenant, by an identity you own. They never touch our infrastructure. See the security page for the full access model.
- Where does the restore go?
- Into a dedicated recovery subscription, fully isolated from your primary - a separate blast radius for region failures and ransomware alike. Your primary environment is never modified.
- Is this a replacement for VM or database backups?
- Not today, and you should not treat it as one. PostgreSQL is the only data source Cloud Parity backs up so far - storage accounts and VM disks are designed for and not built. What Cloud Parity adds now is the layer no data tool has: the network, identities, wiring and workloads that turn data back into a running application. Keep your existing backups; we are not asking you to switch anything off.
- How do we know a recovery will actually work?
- Because it is checked by content, not by exit status. A restored database is compared against the source by row count and per-table checksum, and the artifact is hashed before anything is loaded from it. Running that on a schedule and mailing you the report is not built yet - today someone runs it, and we are happy for that someone to be you, on a call.
Tell us what you’d need to recover.
We’re building Cloud Parity with our first customers. Bring the environment that worries you most and we’ll walk through how it would come back.