Security for your backup tests.
Your tests run in your Kubernetes cluster, where you also manage the credentials for your backups. In RestoreTrust, you schedule tests, assign access permissions, and review the results.
Your Kubernetes cluster
- Retrieve and restore backups
- Run database and file checks
- Use credentials stored as Secrets
RestoreTrust
- Manage sources and test plans
- Assign access permissions for your team
- View results and proofs
From the worker to RestoreTrustStatus updates, logs, and test results
Access backups within your infrastructure
The RestoreTrust worker downloads and tests your backups in your Kubernetes cluster. For database tests, it starts a separate, temporary test database. Each worker belongs to one project and runs the tests assigned to it within that project. The central RestoreTrust application does not access your backup storage directly.
Status updates, logs, and check results are sent to RestoreTrust. This is also where you manage sources, test schedules, and access permissions. Your cluster’s location determines where the tests run; settings and results are also processed centrally.
Manage your own credentials
Store the credentials for your backup sources as Kubernetes Secrets in your cluster. In RestoreTrust, enter the name of each Secret. The test environment uses the values locally. The same applies to any archive passwords and decryption keys you need.
You change and delete these Secrets in your cluster. They remain there even if you delete a project or your organisation in RestoreTrust.
Protect accounts and control access
Protect your account with two-factor authentication. Recovery codes let you regain access if your second factor is unavailable.
Use roles to decide who can manage your organisation, change technical settings, edit test schedules, or only view results. For automated access, create API keys with specific permissions and an expiry date. Each key applies to one project; organisation and billing management remain restricted to signed-in users with the required permissions.
Limit network access
The worker installation sets up network rules for the test environment. Your cluster’s network plugin must support Kubernetes NetworkPolicies for these rules to take effect. An optional admission policy protects the rules against unauthorised changes that would widen access. This requires Kubernetes 1.30 or later.
See Execution for how to set up the worker and control access to your backup sources.
Track changes and test results
Depending on your plan, a change log records actions such as changes to access permissions and who made them. Password, token, and other credential fields are masked. If you switch to a plan without a change log, existing entries are deleted.
You can receive test results by email or webhook. Webhooks require a publicly reachable HTTPS endpoint; private and reserved network addresses are blocked.
Verify test evidence independently
Each completed test has a SHA-256 hash of its recorded test data. An optional OpenTimestamps proof confirms that those data existed in that form no later than the confirmed time. You can download the test data as JSON and the proof as an .ots file, then verify them independently once confirmation is complete.
The timestamp establishes that the test record existed. The test and your chosen checks show what could be restored from your backup. See Reports for more about what the proofs establish and how to create PDF reports for audits.
For your security review
RestoreTrust does not currently hold ISO 27001 certification or a SOC 2 report. The Compliance pages explain how you can include backup tests in your own documentation. If you have questions about your security requirements, get in touch.