Restore testing for databases outside the managed safety net: self-hosted Postgres on VMs, Hetzner, DigitalOcean or on-prem, and the off-site pg_dump copies you keep of Supabase, Neon or RDS.
RecoverProof restores your database backups on a schedule, checks that the data is complete, fresh and uncorrupted, and alerts you the day a backup stops being recoverable. Tests run inside your own infrastructure, so your data never leaves it. Every test leaves evidence you can hand to an auditor.
Backup jobs report "success" when a file was written. They don't tell you whether that file restores, how long it takes, or whether the data inside is what you think it is.
Dumps that end halfway, a cron job that died months ago, a bucket lifecycle rule that deleted last week's files.
Backing up a replica that stopped replicating, or the staging database by mistake. The file restores fine; the data is old.
SOC 2, ISO 27001 (control 8.13) and NIS2 ask you to test restores regularly and keep records. Most teams do it by hand once a year, if at all.
You run a small RecoverProof runner (one Docker container) next to your backups: on a server, as a Kubernetes CronJob, in CI or in your cloud account. Nothing changes in your backup setup, and no backup data is sent to us.
The runner pulls the latest backup from S3, Cloudflare R2, Backblaze B2 or Google Cloud Storage using read-only credentials that stay with you.
It restores the backup into a throwaway, network-isolated database on the same major version you run in production.
It runs the integrity and data checks below, then deletes the restored database and the backup copy.
Only measurements reach RecoverProof: row counts, timings, pass/fail. We compare them with previous runs, alert you, and build your evidence report.
Every test checks your data in layers, each catching a different kind of failure.
Illustrative example of a failed test.
Each month you get a PDF report listing every restore test, its result, measured restore time and any incidents with when they were fixed. It maps to the restore-testing requirements in SOC 2 (A1.3), ISO 27001 (8.13) and NIS2 (business continuity).
Backups are restored inside your infrastructure. We never receive backup files, rows or credentials, and never connect to your production database.
The runner's source code is open for your security team to review, and the exact report it sends is documented. Table names can be hashed if even those are sensitive.
The runner needs read-only access to the backup bucket and an outbound HTTPS connection. No inbound access to your network. Prefer us to run it? A hosted option is available too.
We're onboarding a small group of teams first, starting with PostgreSQL pg_dump backups in S3-compatible storage. Early teams get founding pricing and a say in what we build next.
First: PostgreSQL logical dumps (pg_dump custom, directory, tar or plain SQL, optionally gzip/zstd compressed) stored in S3-compatible storage. MySQL dumps and RDS/Aurora snapshots are next. Tell us what you use in the form; it decides what we build after that.
Early access starts with databases up to tens of gigabytes. Because the runner uses your own compute, size mostly depends on the machine you give it; tell us your size.
You can, and some teams do. The hard parts are keeping it running, noticing when the script itself silently breaks, building useful data checks and history, and producing evidence an auditor accepts. RecoverProof is that script, maintained and monitored. If you'd rather build it yourself, here's how.
Probably not first. AWS Backup can already restore snapshots on a schedule and report on it; checking the data inside is left to Lambda functions you write. RecoverProof is built for what that doesn't cover: self-managed databases, providers outside AWS, and independent off-site copies (often kept for ransomware or account-compromise scenarios) that nobody ever tests. It also checks the data itself out of the box and keeps a history to spot anomalies.
No. Restores happen inside your infrastructure, run by the RecoverProof runner. It sends us only measurements: row counts per table, timings, schema fingerprints and pass/fail results, never rows, files or credentials. You can read the runner's code and inspect every report it sends. If you'd rather not run anything yourself, we also offer a hosted option with isolated, in-memory restores that are deleted after each test.
Yes, that's planned for the first version: you provide a key scoped to decrypt only. With the runner, the key stays in your infrastructure and never reaches us.