Restore verification
We restore real backups into isolated environments on a size-based cadence, confirm the database starts and passes checks, and record the timings.
A backup job that exits zero has proved that a backup job exited zero. Verification is the part that proves the backup restores.
It runs on a schedule you do not have to start, and the result is the Last verified restore date on your service.
Check yours
- Open the service and select the Backups tab.
- Read Last verified restore.
Until the first verification completes it reads Not measured yet. Your first one is due within 48 hours of your first successful backup.
The same column is on the services list and on the Backups screen, so you can see every service at once.
What a verification run does
- Restores one of your real backups into an isolated temporary environment
- Replays the write-ahead log
- Starts PostgreSQL and confirms it accepts connections
- Runs consistency checks against a sampled set of relations
- Records the timings
- Destroys the environment
Your service is not touched and its performance is not affected. The restore happens somewhere else.
Cadence
The interval follows database size, because restoring a 2 TB database is expensive and restoring a 20 GB one is not.
| Database size | Full restore test |
|---|---|
| ≤ 50 GiB | Every 7 days |
| 50–250 GiB | Every 14 days |
| 250 GiB – 1 TiB | Every 30 days |
| Over 1 TiB | Every 60 days, plus a monthly point-in-time test |
The boundaries are binary and inclusive: 50 GiB is 53,687,091,200 bytes, and 1 TiB is 1024 GiB. A database of exactly 50 GiB verifies every 7 days. Every size we publish is binary, so a database of 52 decimal GB is still in the first band.
Regardless of cadence, a verification also runs:
- within 48 hours of a service's first successful backup
- after any plan change, storage expansion or major version change
- after any change to backup configuration or repository
- after any archive pipeline failure is resolved
Continuous checks in between
- Archive pipeline monitoring, continuously
- Repository and archive consistency, daily
- Repository checksum verification, weekly
What verification measures, and what it does not
A verification run measures restore and replay, uncontended, on a dedicated host, for one database, with the target already available.
Real recovery includes detection, decision, host selection, provisioning, fencing, the restore, the replay, the endpoint change and its propagation, usually while several services are being recovered at once.
So restore_test_duration is a lower bound on recovery, not a recovery time. Any recovery time
we publish comes from scheduled drills that include restoring from the second repository and
recovering every service from a failed host concurrently.
What you will see
A date, and whether the run passed or failed. A failed verification is one of the six conditions that emails you. See alerts.
Troubleshooting
It reads "Not measured yet" on a service more than 48 hours old. That is a condition we alert on.
Contact support any time by email or from your dashboard. Every service is monitored around the clock.
The date is older than the cadence table says it should be. Check the service's size band: a database that has grown across a boundary moves to the longer interval.
A verification failed. You are emailed when it does, and the alert stays open until a member of staff closes it with a note. Do not assume a later success closed it.