An example with PostgreSQL and S3
Suppose your team backs up a PostgreSQL database every day as a compressed SQL dump in S3-compatible storage. The backup job reports success. What matters to your team, though, is whether the latest file can be downloaded, restored, and queried when you need it.
RestoreTrust lets you check this regularly. The steps below describe one possible setup, rather than a report about a particular customer.
Set up access once
First, install a RestoreTrust worker in your Kubernetes cluster and assign it to a project. Add the backup source to that project. The worker must be able to reach the storage location, and the cluster needs enough capacity for the download and restore.
Store the storage credentials as a Kubernetes Secret in your cluster. In RestoreTrust, enter the name of the Secret, not its contents. The worker can then access the source during a test, while you continue to manage the credentials where the test runs.
In the test schedule, select the source, path, and worker. For this example, choose the latest matching backup file. A filename pattern narrows the selection; a maximum age keeps an outdated file from passing unnoticed. Then select PostgreSQL, a version that matches the backup, and the SQL dump format.
Check what matters to your team
A test database starting up does not, by itself, answer every question you have about your data. Add checks of your own: for example, a query that must return an expected value. You can also set a time limit for a test step.
The right criteria depend on your application. In this example, the team might check a table it relies on in daily work. That gives the test a clear purpose beyond completing the restore.
Now schedule the run, perhaps every day after the backup job. You can also start the first test manually. The available scheduling intervals depend on your plan.
What happens during the test
At the scheduled time, the worker downloads the selected file from storage. It restores the backup into a temporary database, separately from your production database, and runs your checks against the restored data. The test environment is removed when the run finishes.
In the RestoreTrust Console, you can see which backup was used, whether the download and restore succeeded, and how each check turned out. If something fails, you can identify the affected step, investigate the cause, correct the backup or test schedule, and run another test.
Put the results to work
Set up email or HTTPS webhook notifications if your team wants to hear about every run or just failures. The test history remains available in the Console. Depending on your plan, you can bring several runs together in a PDF report for an internal review or an audit.
Each completed test also has a SHA-256 hash of its recorded test data. An optional OpenTimestamps proof can be verified independently once it has been confirmed. It shows that the test record existed in that form no later than the confirmed time. The run and your chosen checks show what the backup yielded. Read more about reports and proofs.
Start with the backup you care about most
You can follow the same approach with MySQL, MariaDB, and MongoDB, or with backups stored on FTP, SFTP, or SMB. For files without a database, separate file checks test the download and your file age and size requirements.
Start with a backup your team would need early in an incident. When the checks reflect that system, each run gives you a concrete answer about what could be restored from the selected backup under the conditions you chose. Explore how RestoreTrust works.