Checked at the destination
As soon as a backup is written, the platform checks that the copy at its destination exists and is the size that was written: a signed request for the object in cloud storage, or a look at the file on the server’s own disk. A copy that passes is marked as stored.
A copy that is definitely missing or the wrong size fails the backup that night. An answer that proves nothing either way, such as storage refusing the request, is recorded as could not run and the backup stands.
Weekly restore tests
Each source’s newest good backup is fetched onto its own server and compared with the SHA-256 checksum recorded when it was taken. The archive is then read to confirm it is valid.
The database dump is loaded into a scratch database with a name the platform generates, never the live database, and every table is read back. The scratch database is dropped afterwards, including when the test fails.
What reading every table proves
On MySQL and MariaDB each table is checked with CHECK TABLE. On PostgreSQL every table is counted in full, which reads every data page and fails on a damaged one. A dump that loads but holds a table that cannot be read fails the test.
Scheduled events are removed from a MySQL dump before it is loaded, because an event runs the moment it exists and can write to other databases on the same server, including the live one.
A copy that fails stops counting
A backup that fails verification is marked as failed and retention no longer counts it. Keeping three copies then means keeping three that work: if the newest copies all fail, the older one that would still restore is not the one deleted.
Live data is not touched
Restore tests do not read or write the source directory and never target the live database. The work runs at the lowest CPU and disk priority the server offers, so the server keeps serving traffic while its backup is tested.
The space a test needs is measured before anything is written, and on MySQL the scratch load is kept out of the binary log, so replicas never receive it. Tests run in the hours after the source’s own scheduled backups, when the server already expects heavy work.
You can also test any backup yourself with Test restore.
Failed versus could not run
If a test cannot run, for example because the server is unreachable or its disk is full, the result says nothing about the backup. It is shown as a warning, not as a broken backup.
A test that shows a backup would not restore is recorded as failed and emails the account.
Frequently asked questions
- How often are backups restore-tested?
- Each source’s newest good backup is restore-tested every seven days. You can test any backup yourself at any time.
- Does a restore test touch my live database?
- No. The dump is loaded into a separate scratch database with a generated name, which is dropped afterwards.
- Where does the test run?
- On the server the backup came from. The platform does not copy your data to its own infrastructure to test it.
- What if a test cannot run?
- It is recorded as could not run, with the reason, and tried again later. It does not mark the backup as broken.
- Am I notified when a backup fails verification?
- Yes. A failed verification emails the account and appears on the backups page and the dashboard.
Key points
- Every backup checked at its destination
- Weekly restore test of each source’s newest backup
- Checksum compared, archive read, database loaded and read back
- Scratch database dropped; live data untouched
- Could not run reported separately from failed