Why a dedicated tool rather than pg_dump in a crontab
The most common backup fits on one line: a pg_dump run nightly by cron, compressed into a directory. It works until the day you find out it had been failing for three weeks with nobody notified, that the disk was full, or that the file does not restore for lack of the right role.
Databasus addresses exactly those blind spots: it reports every failure, applies a retention policy, ships copies off the machine, and proves that they restore. For PostgreSQL it adds what a dump cannot do: incremental physical backups and WAL streaming, which let you roll back to the minute before a mistake.
What Databasus gives you
- Physical and logical PostgreSQL — full and incremental backups, WAL streaming and point-in-time recovery (PITR).
- MySQL, MariaDB, MongoDB — compressed logical backups from the same interface.
- Fine-grained scheduling — hourly, daily, weekly, monthly or a cron expression.
- Verified restores — a real restore into a temporary database and a per-table report.
- Many storages — local disk, S3, Cloudflare R2, Google Drive, SFTP, Rclone.
- AES-256-GCM encryption — files stay unreadable even on shared storage.
- Teams — workspaces, roles, audit log and email, Telegram, Slack or webhook notifications.
Databasus versus the usual methods
Scroll the table
| Databasus | pg_dump + cron | VPS snapshot | |
|---|---|---|---|
| Alert on failure | Yes, several channels | Write it yourself | Depends on the host |
| Point-in-time recovery | Yes (WAL streaming) | No | No, only the snapshot time |
| Off-machine copy | S3, R2, SFTP, Drive… | Script it | At the host |
| Verified restore | Automatic, with a report | Manual | Manual |
| Granularity | Per database | Per database | The whole disk |
| Interface and team | Yes, roles and audit | No | Host console |
Prerequisites
An Ubuntu 24.04 VPS with 1 GB of RAM is enough to drive the backups; plan disk space if you keep local copies, or an S3 or R2 bucket to send them elsewhere. You need Docker with the Compose plugin. On the database side, you need network access from the VPS and a user dedicated to backups.
If your databases run on other servers, open their port only to the IP address of the Databasus VPS, never to the whole Internet: a firewall that accepts only that source limits exposure to a single machine you control. For a database on the same VPS, no inbound port needs to be opened.
Install Databasus with Docker Compose
Create the Compose file
Create an
/opt/databasusdirectory and put thisdocker-compose.ymlin it. The port is published on the loopback only, andextra_hostslets the container reach a database installed on the VPS itself through the namehost.docker.internal.services: databasus: image: databasus/databasus:v3.62.0 restart: unless-stopped ports: - "127.0.0.1:4005:4005" extra_hosts: - "host.docker.internal:host-gateway" volumes: - databasus-data:/databasus-data volumes: databasus-data: {}Start the container
Start Databasus and follow its boot:
docker compose up -d docker compose logs -f databasusOn first start, the image initialises its own metadata database and applies its migrations in the
databasus-datavolume. The linehttp server listening on :4005tells you it is ready, within seconds.Open the interface and create the account
From your machine, open an SSH tunnel to the VPS:
ssh -L 4005:127.0.0.1:4005 root@<ip-vps>Then go to http://localhost:4005 and create your account: the first account created becomes the administrator. Later sign-ups stay open by default with a member role, so turn off external registrations in the settings.
Declare a PostgreSQL database
On the PostgreSQL server, create a dedicated role that can only read:
CREATE ROLE databasus WITH LOGIN PASSWORD 'a-long-password'; GRANT pg_read_all_data TO databasus;In Databasus, add the database with its host (for a database on the same VPS:
host.docker.internal), its port, that role and its password, then a storage destination and a schedule. Run a first backup by hand to check that it completes.
Always keep a copy off the VPS
A backup kept on the server's disk protects against an unfortunate DROP TABLE, not against losing the machine. Add at least one external destination — an S3 or R2 bucket — and enable encryption: the file is then useless to anyone who reaches it without the key.
Pick a retention policy
Databasus offers four ways to bound history: a duration (keep seven days, three months, a year), a count (the last thirty), a GFS rotation (grandfather, father, son: hourly, daily, weekly, monthly and yearly copies kept independently) and size caps, per backup and in total.
For a production application, a good starting point is a daily backup kept for thirty days, plus a monthly GFS rotation over a year, and a total size cap that keeps storage from overflowing. Add WAL streaming if losing a day of data is unacceptable.
Check that restores work
This is the feature that sets Databasus apart. After each backup, or on a schedule, it starts a temporary database, restores the copy into it, compares the resulting size with the backup's and lists every table with its row count. The report can be sent to you, or only the failures.
Schedule at least a weekly verification of your most important database. On the day of an incident you will not discover a missing extension or role: the verification will have told you weeks earlier.
Keep a record of these reports as well: they are dated proof that your recovery plan has been exercised. It is often the first question a client or an auditor asks after an incident, and the answer "we restore every week, here are the reports" closes the discussion.
Troubleshooting
Connecting to a database on the same VPS fails. The database server only listens on 127.0.0.1: add the Docker network interface to listen_addresses (PostgreSQL) or bind-address (MySQL), allow the Docker subnet in pg_hba.conf, then restart the service.
A backup to S3 fails. Check the region, the bucket name and the access key's rights: it must be able to write, list and delete objects under the chosen prefix, otherwise retention cannot purge old copies.
No notification arrives. Test the channel from its settings page; for email, an SMTP server must be set in the settings.
The interface stops responding. Read the logs with docker compose logs --tail 100 databasus: every background job is logged at start-up.
One-click install from the ServOrbit Marketplace
The ServOrbit Marketplace installs Databasus on your VPS with no command line: it deploys the container with host.docker.internal access already declared, publishes the port on the loopback and shows in the client area the port to use for the SSH tunnel. You can also attach a domain for permanent HTTPS access.
