Overview

RestoreTrust regularly restores backup files in an isolated environment and records whether the restore and the checks you configured succeeded.

It is designed to answer a practical question: can this backup be downloaded, decoded, restored, and checked by the infrastructure you selected?

What you can validate

RestoreTrust supports:

• PostgreSQL, MySQL, MariaDB, and MongoDB restores
• File existence, age, and size checks
• Backups stored in S3-compatible object storage, FTP, SFTP, or SMB
• Password-protected ZIP and age-encrypted backups
• Scheduled and manual checks
• Email and HTTPS webhook notifications
• Check logs, reports, SHA-256 evidence, and optional OpenTimestamps anchoring

Available database versions are shown in the console. Choose the version that matches the backup rather than relying on a version listed in documentation.

How a check works

1. You configure an organization and project.
2. You install a project worker in your Kubernetes cluster.
3. You register secret metadata and create the corresponding Kubernetes Secret in the worker's job namespace.
4. You configure a source and a schedule.
5. The selected project worker downloads the matching backup, restores or inspects it, and evaluates the configured criteria.
6. RestoreTrust records the outcome and can notify your selected channels.

Credential values stay in the Kubernetes Secret in your cluster. RestoreTrust stores the secret's metadata and name so the worker can reference it; it does not store the secret values.

Start here

Use the Quickstart to complete a first check. Before installing a worker, review the requirements and how RestoreTrust works.