Databasus just shipped restore verification. The idea behind it is short. A backup job that ends with "success" only proves the dump command ran. It does not prove you can restore the file it produced. Restore verification closes that gap. It takes your latest backup, restores it into a throwaway database container and checks that the data actually came back.

Databasus is the most widely used tool for PostgreSQL backup, and it already handles logical, physical and point-in-time recovery backups. Restore verification is the piece that now confirms those backups will actually restore. You can read the full feature docs on the restore verification page. The rest of this article covers what it does, how the report reads and how to switch it on.

A backup that finished is not a backup you can restore

Here is the uncomfortable part of running backups. Most setups check two things and call it done. They check that the backup job did not throw an error, and sometimes they check a file checksum. Both checks are real and worth having. The trouble is that neither one tells you the backup will restore.

A dump can exit with code 0 and still be missing data. A role without read permission on certain tables can make the dump tool skip those objects quietly. So can a missing extension on the source or a tablespace mismatch. None of that shows up in an exit code, and a checksum will happily confirm that an incomplete dump is a perfectly intact file.

A green backup status and a matching checksum are both fine to have. They just leave one question open, and it is the question that matters most. Restore verification is the check that answers it directly.

What restore verification does

When a verification runs, it does not parse the backup or simulate a restore. It performs a real one. The sequence is the same every time, and it is easy to follow from start to finish.

• Pulls the most recent successful backup for the database
• Spins up a fresh database container and restores the archive into it with the engine's native restore tool
• Counts the rows in every table and checks the restored size against the backup
• Destroys the container along with everything inside it
• Sends the result back to Databasus

Each run is self-contained. It never touches your production database, and it leaves nothing behind once the check is done.

Inside a real database container

The restore does not run against your live server. Databasus starts a separate Docker container for the job, on the host where the verification agent runs. That container runs the matching database engine, so the restore uses the real tooling instead of an approximation of it.

Running it this way has a couple of practical upsides. The check cannot interfere with production traffic, because it never connects to the production server at all. And since the container is disposable, a verification can restore a full database without you hunting for spare space on a real instance. When the run finishes the container and its data are deleted, so a week of daily checks will not slowly fill a disk.

This is the part the feature name points at. Your backup gets proven against a real engine in a real container, and then that container is thrown away.

Reading a verification report

Every verification leaves a report behind. At a glance you get a status, which is enough to see whether anything needs attention. Open the run itself and you get the detail, including exactly what came back from the archive.

The per-table row counts are the part worth watching. If a table you expect to be large comes back empty, the report shows it now, long before the day you actually need that backup to restore.

Turning it on with a verification agent

Restore verification is heavier than a normal backup job. It downloads a full backup, starts a database and runs a restore. Work like that does not belong inside the main Databasus container, so it runs on a small separate worker called the verification agent.

The agent is a single lightweight Go binary. You create it in the Databasus UI first, which gives you something to register against, then you launch the binary on a host you control. It dials out to Databasus, picks up verification jobs from a queue and reports the results back. You can run it next to Databasus or on a different machine, whichever suits your hardware.

Once it is running and registered, the agent appears in Databasus and starts taking jobs.

What the agent host needs

The agent does not ask for much, but it does have a few hard requirements. Most of them follow from the fact that it runs real databases in Docker. It is worth checking these before you launch it.

• Outbound HTTPS access to your Databasus URL, since the agent dials out and is never exposed
• Docker installed and running on the host
• Free disk of roughly twice your largest backup, with at least 1 GB of headroom
• At least 1 CPU core and 512 MB of RAM for every verification running at the same time

If a host already runs Docker and has some disk to spare, it can almost certainly run an agent.

Setting a resource budget

You will not want a verification to consume the whole machine, so the agent runs inside a budget. You pass four flags when you launch it, and Databasus divides that budget across the jobs it sends to the agent.

There is a floor of 1 CPU core and 512 MB of RAM per job. If your budget cannot cover that floor for the concurrency you asked for, the agent does not fail. It simply advertises a lower number of concurrent jobs and works within what it has. Set the budget once at launch and the agent stays inside it.

Schedules, the queue and notifications

You decide how often each database gets verified. There is no single right cadence, so Databasus gives you three ways to trigger a run, and you pick whichever fits the database in front of you.

• After every successful backup, the moment it finishes
• On an hourly, daily, weekly or monthly cadence at a time you choose
• On a custom UTC cron expression for anything the presets miss, for example 0 4 * * 0 for every Sunday at 04:00

The "after every backup" option raises a fair question. What if backups arrive faster than verifications can finish? Databasus handles that by cancelling any pending verification for a database as soon as a fresher backup shows up. Only the most recent backup waits in line, so checks never pile up and you always verify the newest data.

You can also run a one-off verification by hand. Each database has a "Restore verifications" tab, and from there you can start a single check without changing the schedule. It is handy for spot-checking one particular backup, or for testing a new agent right after you set it up.

Results can go to any notifier already wired to the database, so Slack, Discord, Telegram, email and the rest all work without extra setup. There are two separate toggles, one for verification success and one for verification failure, and they are independent of each other. Most teams switch on the failure one only, since a constant stream of "it worked" messages tends to get ignored after a while.

Set a trigger once, point it at the notifiers you already use and the database keeps verifying itself from there.

Conclusion

Restore verification changes what a backup status means. Instead of "the dump finished", you get "the backup restored into a real database, and here are the row counts". That is the difference between hoping a backup works and knowing it does.

Databasus is a free, open source and self-hosted backup tool, and it has become an industry standard for PostgreSQL backups. It is Apache 2.0 licensed, with more than 600,000 Docker pulls, around 7,000 GitHub stars and over 30 contributors. Restore verification ships in the same open source build as everything else, with no paid tier and no feature gate, and the code is all on GitHub.

If you already run Databasus, set up an agent and turn verification on for your most important database first. If you do not run it yet, this is one of those features worth having in place well before the day you actually need a backup to come back.