Open the demo

A backup you have never restored is a hope

Restorly restores every backup it is given, on a schedule, checks that the data is really there, and signs a report anyone can verify. On your servers, inside your network.

Open the demo Check a report
The Restorly panel: every database with its last result, backup age, restore time and checks; what needs attention; runners and monthly reports.
1

Find

Backups where they already land

 2

Restore

In a throwaway, offline container

 3

Check

Integrity, consistency, your own SQL

 4

Sign

A report anyone can check
1 · Find

It finds your backups where they already are

No new backup tool. Point Restorly at the place your backups land and describe how the files are named; the panel shows which files match and which is the newest, live, as you type.

  • Local disk and NFS
  • NAS over SMB
  • SSH / SFTP hosts
  • AWS S3
  • Cloudflare R2
  • Google Cloud Storage
  • Backblaze B2
  • Wasabi
  • MinIO and Ceph

Many databases on one server? Set up one, then import the rest at once (Business and Enterprise).

Adding a database: the naming pattern webshop-{YYYY}-{MM}-{DD}_{hh}{mm}.sql.gz and a live preview of the three matching backups, the newest highlighted.
2 · Restore

It restores them, out of harm's way

Each backup is restored into a fresh container of the same database version, on a host you control. The container has no network and no published ports, it is removed after the test, and production is never written to.

  • MariaDB
  • MySQL
  • PostgreSQL
  • MongoDB
  • Microsoft SQL Server

Logical dumps, MariaDB and PostgreSQL physical backups, pgBackRest repositories, mongodump archives and SQL Server .bak files. SQL Server runs under your own licence settings.

The two newest major versions of each database, with every minor release: MariaDB 12.x and 13.x; MySQL 9.x and 26.x; PostgreSQL 17 and 18; MongoDB 8.x and 9.x; SQL Server 2022 and 2025.

A restore test The newest backup is read from its location and restored into a container of the same version, which has no network and resource limits; the checks run on it; the container is removed after each test. Production is never written to. Newest backup shop.sql.gz NAS · SFTP · S3 Production never written to Isolated container MariaDB 12.3 same version restored in 4 min No network no ports, no egress Limits CPU, memory, disk removed after each test
3 · Check

It proves the data is there, not just that it restored

  • Integrity The backup exists, is fresh, is not truncated or garbage, and matches its checksum.
  • Restore It restores without errors; the restore time is tracked, so a growing recovery time shows up early.
  • Consistency CHECK TABLE or amcheck, row counts against the previous run and, optionally, production; schema drift, emptied tables, sampled table fingerprints.
  • Your own checks SQL you write with an expected result, run read-only on the restored copy and stored in the report exactly as it ran.
A run: the signature is valid and every check passed, from integrity to two custom SQL checks.
4 · Sign

It signs a report anyone can check

Every run produces a report signed with the install's own Ed25519 key and chained to the one before, so a removed or edited report is detected. The PDF is a rendering of the signed report and can be checked against it. Your auditor checks both at demo.restorly.eu/verify, in the browser. Monthly summaries are ready to forward.

For audits, an evidence report maps a period of signed reports to the backup controls of NIS2 (Implementing Regulation 2024/2690, point 4.2) and ISO/IEC 27001 (A.8.13 and A.5.30): what is covered, where the gaps are. Evidence for your auditor, not a certificate.

Hash-chained signed reports Reports 51, 52 and 53, each signed and each holding the hash of the one before; changing or removing one breaks the chain. Report #51webshoppassed, 8/8prev 3b7a…hash 9f2c…✓ signed Report #52crmpassed, 6/6prev 9f2c…hash 41ab…✓ signed Report #53billingpassed, 6/6prev 41ab…hash 7d0e…✓ signed Check any report, JSON or PDF, in a browser at restorly.eu/verify, with nothing to install: who signed it, whether it changed, its place in the chain.

When you want more

It takes the backups too

Backup mode dumps production as a read-only user, stores the backup at your location, rotates old ones, and validates each new backup right after it is written.

A safe copy for developers

After each sound validation, personal data is masked by your rules in the restored copy and written out as a fresh dump for development and testing. Unmasked personal-looking columns are flagged.

Point in time

For PostgreSQL and MariaDB, archived logs are replayed on the newest backup, so you see how much data a restore right now would get back, and notice when log archiving quietly stopped.

Your recovery key

For encrypted backups, prove that the key you keep offline still opens the newest backup. The key is used once, in memory, and never stored.

The panel

Every database at a glance, and its history

Each database shows its newest backup's age, how long restores take over time, every check and every run. Something off is at the top of the overview, with what to do about it; email, Slack, Teams or a webhook tell you before you look.

A database's page: backup age 19 hours, restore 4 minutes, 8 of 8 checks, the restore time over the last 30 runs and every run passed.

Where it runs

On a Linux host inside your network, with Docker or Podman. The panel listens there; more runners can join from other sites or network segments and dial out to it. Installation takes a signed package from our repository; updates are signed releases you approve.

  • Linux x86_64 or arm64
  • Docker or Podman
  • 4 vCPU · 8 GB RAM
  • Works offline
Open the demo Check a report