Recovery
Measured, not promised
Every recovery time below comes from drills run against real customer data in the last 90 days.
Measured recovery times
| Scenario | Method | p50 | p95 | Drills |
|---|---|---|---|---|
| Single file, 10 GB | index restore | 40 s | 2 min | 6,110 |
| Mailbox, 60 GB | SaaS granular | 9 min | 26 min | 2,884 |
| VM, 500 GB | instant boot from vault | 94 s | 4 min | 3,902 |
| VM, 500 GB | full restore to production | 22 min | 51 min | 1,441 |
| PostgreSQL, 2 TB, PITR | base + WAL replay | 38 min | 1 h 24 | 718 |
| Site failover, 40 VMs | orchestrated runbook | 1 h 51 | 3 h 12 | 204 |
| Bare metal, dissimilar hardware | driver injection | 48 min | 1 h 39 | 312 |
How a drill runs
01
Clone
The recovery point is cloned into an isolated network with no route to production.
02
Boot
VMs are started in dependency order using the runbook you defined.
03
Verify
Health checks you specify — a TCP port, an HTTP status, a SQL query, a script exit code.
04
Report
Pass or fail, with timings, screenshots and a signed record for the auditor.
Recovery questions
The VM runs directly from the vault over NFS or iSCSI while its disks stream back to production in the background. Useful when the alternative is waiting an hour.
Yes — DR-as-a-service on the Business plan and above. Your workloads run in our compute region until you cut back.
It pages your on-call, not ours, because a failing drill is a problem in the protected system nine times out of ten. We include the diagnostics.
Yes — dependency ordering, IP re-mapping, DNS updates and script hooks at every stage. The runbook is exercised on every drill, so it does not rot.