Most people think they have backups.
Most people do.
They have snapshots. They have another copy in another region. They have something called "Backup" in a control panel somewhere. And most of the time, that's enough.
The problem is that backups are usually evaluated using the wrong criteria. People compare storage size, retention periods, regions, restore speed and price per terabyte. Those things matter, but they are secondary. The first question should be much simpler:
The answer to that question tells you more about a backup strategy than any feature comparison ever will. So let's walk up the failure ladder.
Level 1: You failed
This is the most common incident in infrastructure. A migration goes wrong. A deployment deletes something it shouldn't. Someone runs a command in the wrong directory. A package upgrade breaks a service. This is not a disaster, it's a mistake.
Snapshots are perfect for this: roll back, restore, move on. Operational recovery is about recovering from your own actions quickly and with minimal disruption, and snapshots excel at that.
Level 2: Infrastructure failed
A disk dies. A server dies. A node disappears. Good infrastructure is designed around the assumption that hardware will eventually fail, so replicated storage, clustered systems and distributed storage platforms handle these events every day. If your snapshots live on replicated storage, they survive too.
This is important, but it isn't where disaster recovery starts. Modern infrastructure should already be resilient to individual hardware failures.
Level 3: The cluster failed
This is where things become interesting. A storage cluster is not immortal: datacenters fail, entire regions go offline, large-scale outages happen. When that happens, snapshots usually disappear together with the infrastructure they were protecting. This is the point where many people discover they never had disaster recovery at all. They had operational recovery.
A snapshot is an excellent rollback mechanism, but it still lives inside the same failure domain as the workload it protects. If the cluster becomes the incident, the snapshot becomes part of the incident too. Disaster recovery begins when a copy exists outside that blast radius: different storage, different location, different failure domain.
Level 4: The provider failed
This is the failure domain almost nobody talks about. Many backup strategies stop at geography, assuming that if a copy exists in another region, disaster recovery has been solved. Sometimes that's true. Often it isn't.
Imagine two copies stored in different regions of the same provider. They are still attached to the same account, the same billing system, the same support organization and the same legal entity. Now imagine a billing dispute, an account suspension, a mistaken fraud flag, a compliance review or a legal hold. None of those care which region your data lives in.
The organization did.
And when the organization becomes the incident, every copy inside that organization becomes part of the incident too. This is why we think disaster recovery should consider organizational failure, not just infrastructure failure. A backup stored in another provider is fundamentally different from a backup stored in another region of the same provider.
We also protect you from provider failure. Including ours.
Level 5: We failed
This is the question almost nobody asks: what happens if the backup provider itself becomes part of the incident? Not the storage, not the datacenter. The provider.
Imagine the control panel is unavailable during the exact moment you need to restore. Imagine support is unreachable, the API is down, or the company no longer exists. Can you still recover your data? If the answer is no, then your recovery plan depends on something you do not control.
We think a disaster recovery system should survive the company that built it. That's why backups are stored outside our infrastructure, encrypted with your key and recoverable without our control panel, our API or our involvement.
The uncomfortable truth
What they actually have is a collection of assumptions.
They assume the storage survives. They assume the account survives. They assume the provider survives. They assume the recovery tooling survives. Most of the time, those assumptions are correct. Disaster recovery exists for the day they aren't.
The one thing this doesn't protect you from
Every system has limits. Any disaster recovery design eventually reaches a failure scenario it doesn't cover, and pretending otherwise is marketing, not engineering. For us, that scenario looks something like this: two independent providers fail, in two independent countries, at the same time, and you lose your own encryption key.
At that point the problem is no longer provider failure. It's a global event combined with a key management failure, which is outside the scope of any realistic disaster recovery plan. Everything short of that should be survivable.
The whole ladder
| Failure | Still have data? |
|---|---|
| Bad migration | Yes |
| Accidental deletion | Yes |
| Dead disk | Yes |
| Dead node | Yes |
| Dead cluster | Yes |
| Dead datacenter | Yes |
| Locked account | Yes |
| Provider disappears | Yes |
The point
A good backup survives a disk failure. A great backup survives a datacenter failure. The best backup survives its own provider. Because a backup is not defined by where it is stored. A backup is defined by what can die before your data does.
Another company.
Your encryption key.
Recovery without us.
One checkbox.
See what this costs on the Backups & Snapshots pricing page, or the technical reference in the docs.