Restore Testing

Prove your backups actually restore

On a schedule you choose, your newest backup is restored onto a throwaway server on your own cloud and checked, and the server is deleted. If it fails, you hear that day.

A backup nobody has restored is a guess

Most backups are never restored until the day they are needed, which is the worst day to find out one does not work. A test restore finds out on a quiet day instead.

Switch it on for a job, choose how often, and each result appears on the job’s page: passed or failed, which cloud it ran on, and what was found.

From a test restore's log (example values)

Preparing the host for DATABASE/POSTGRESQL
Restoring through the ordinary pipeline (run 3f9c21ab)
Restored database reports 42 table(s)
PASSED — 42 table(s) present
Destroyed DigitalOcean droplet 512345678

And for a file backup

Preparing the host for FILE
Restoring through the ordinary pipeline (run 8d02e7c4)
Found 18204 file(s) under /var/www
PASSED — 18204 file(s) restored under the job's paths; every one matches the backup, byte for byte
Destroyed Hetzner server 61839201

What one test does

Four steps, on your own cloud account, every time the job's test comes due.

Step 1
Build a server that did not exist
A fresh Ubuntu server on your own DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine account, with the database engine or Docker the job needs and an empty database. Empty matters: anything found there afterwards came from the backup.
Step 2
Restore through the real pipeline
The newest successful backup goes through the same code an emergency restore uses: checked against the checksum recorded when it was taken, then restored. A rehearsal through test-only code would prove nothing about the code you would need.
Step 3
Check what came back
Tables in the restored database, collections and documents in MongoDB, files under the job's paths, files inside the job's Docker volumes. A restore that reports success having put nothing back fails here.
Step 4
Delete the server
Whatever happened, pass or fail. The machine is recorded before it is used, so even a test interrupted halfway leaves a record pointing at what to clean up, and a sweep removes it.

What counts as passing

Each kind of backup is checked by what it should have put back. The bar is that something real came back, on a machine that started with nothing.

PostgreSQL, MySQL, MariaDB: The restored database is asked how many tables it has. None is a failure, whatever the restore reported.
MongoDB: Collections and documents are counted in the restored database, after mongorestore has been rehearsed with --dryRun.
Files: Every restored file is compared with the backup, byte for byte. On a throwaway server nothing else is running, so a file that differs fails the test.
Docker volumes: Files are counted inside the job's own volumes, which did not exist on the server before the restore.
Postgres on Railway and Render: Restored into a new Postgres beside yours, in your own Railway project or Render workspace, its tables checked, then deleted. About a cent of platform usage each time.

Four things to know before you rely on it

Where it stops, written down now rather than found out later.

Some backups have nothing to test here

A provider snapshot is restored from the provider's own console, so there is no archive for us to restore. Kubernetes, WordPress sites backed up by the plugin, Cloudflare DNS zones, jobs run by the Agent and Coolify databases are not covered by test restores yet.

It needs a cloud to build on

The throwaway server is built on a DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine connection in your workspace. Without one there is nowhere to run it, and the test reports that it could not run, and why, rather than blaming the backup.

It proves the data came back, not every row

A row-for-row comparison would need your live database and would fail on every row written since the backup. What a test rules out is the failure that matters: a backup that looks healthy and restores nothing.

It runs on your bill, so it is off until you turn it on

Each test is a small server for a few minutes on your own cloud account, usually a few cents. Choose every 30, 90 or 180 days per job. Tests run one at a time, so jobs that come due together queue rather than building servers all at once.

Every other limit is on the features page.

FAQs

Can’t find the answer you’re looking for? Reach out to our support team.

How is this different from checking a backup's checksum?

A checksum proves the file in your storage is the file that was written. It cannot tell you whether that file turns back into a working database. Every backup here is hashed as it uploads and read back from your storage, and a test restore goes the rest of the way: it restores the archive onto a real server and counts what arrived.

Does a test restore touch my real server or database?

No. It restores onto a server it built minutes earlier, into a database it created with credentials of its own, so neither your server nor your database's address or password is ever its target. On Railway and Render it restores into a new Postgres beside yours and leaves the live one alone.

Does my data pass through VPS Snaps during a test?

Normally not. The throwaway server downloads the backup straight from your storage, and each result on the job page says which way the backup travelled. When Railway or Render will not run a restore inside your project, it goes through our worker in memory only, is never written to our disks, and the result says that too.

What happens when a test fails?

You get an alert saying the backup completed and looked healthy but did not restore, with the reason. That is a different message from a test that could not run at all: if the throwaway server cannot be created or reached, the backup was never tried, so it is retried sooner instead, and you only hear about it if it keeps happening.

Which plans include it?

Test restores are not a plan feature of their own. They come with whichever job types your plan includes: file backups on every plan, Free included, and database and Docker backups from Standard up.

The rest of the way back

A tested backup is the start of a recovery. These cover the rest of it.

Powerful features to give you peace of mind

Rest easy knowing your data and your reputation are safe.

Bring your own storage: Backups land in your own S3-compatible bucket — Backblaze B2, Wasabi, Cloudflare R2, or plain S3 — or in your own Google Drive. You hold the keys and the data.
Snapshots stay with your provider: Provider snapshots are created through the provider's own API and never leave your account. We store the snapshot ID, not the image.
Eight providers, one dashboard: DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Google Compute Engine and Microsoft Azure — scheduled and reviewed from the same place.
A replacement server on demand: Recover now builds a new server on your own DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine account, from its snapshot or from its backups, software included.
Failover on any cloud: When a server stops answering, its traffic moves to the recovery server: by reserved or floating IP where your cloud has one, or by your DNS on Cloudflare, which works on every cloud.
Know it's down, with the way back: Uptime monitors for sites, ports and scheduled jobs confirm an outage before alerting, name the server's newest backup, and publish a status page. On paid plans.
Your DNS zones, backed up: Every record in a Cloudflare zone, kept in your own storage as a BIND file too. A restore previews what differs and writes back only that.
Schedules that fit your traffic: Hourly, daily, weekly, monthly, or a fixed interval in minutes — anchored to your timezone, so a 02:00 job stays at 02:00 across a DST change.
Retention that prunes itself: Set how many days to keep. Older snapshots and archives are cleaned up after each successful run, so storage bills stay flat.
Every run on record: Status, duration, size and trigger, with each step it took in order and its warnings and errors kept in place — so a failure tells you which step broke.
Checksummed on upload: Every archive is hashed as it streams to your bucket and the checksum is stored with the run, so you can verify what landed.
Run on demand: Trigger any job by hand before a migration or a risky deploy, without touching its schedule or its retention window.
Alerts on five channels: Email plus Slack, Microsoft Teams, Google Chat, and Discord — on success, on failure, and on a job that missed its schedule entirely.
Encrypted credentials: SSH keys, database passwords, and storage secrets are sealed with AES-256-GCM before they touch the database.
Team access with roles: Invite your team into a shared workspace as owner, admin, or member, so backups outlive whoever set them up.

View all features

“We manage a mix of VPS instances, Docker workloads, and traditional Linux servers, so backups used to be scattered across several different processes. VPS Snaps brought all of that into one dashboard and made it much easier to see what ran, what failed, and what needs attention.”

Chris BennettSystems Administrator

Find out on a quiet day.

Back up a server on the free plan, connect the cloud it runs on, and switch on a test restore for the job. The first test runs as soon as the job has a backup to try.

No credit card required. Cancel anytime.

Prove your backups actually restore

A backup nobody has restored is a guess

What one test does

Build a server that did not exist

Restore through the real pipeline

Check what came back

Delete the server