Deployment guide

Databasus

Overview

This is Databasus 3.50.0, unmodified, on Ubuntu 24.04 LTS, packaged by SecureAnyCloud for the Azure Marketplace.

Databasus is an open-source, self-hosted backup tool for PostgreSQL. It takes scheduled physical and logical backups, streams write-ahead log data for Point-In-Time Recovery, verifies that backups can actually be restored, and applies retention policies. It pushes the results to storage you control: local disk, S3, Azure Blob Storage, Google Drive, SFTP and more. It also backs up MySQL, MariaDB and MongoDB.

What you get:

Databasus 3.50.0, the product: a web interface plus REST API, listening on port 4005 on all interfaces.
PostgreSQL 17, a bundled demo database that is there to be backed up, listening on 127.0.0.1 only, port 5432.
A single VM with no cluster to plan and no external dependency.

The demo database makes the appliance useful the moment it boots. You can take a real backup, watch it succeed and confirm a restore without wiring anything up first. It is configured for Point-In-Time Recovery, not just simple dumps.

When you are ready to protect your own databases, you add them in the web interface, and the demo database simply stops mattering.

Security posture, set on first boot

Two things about a stock Databasus install are unsafe on a public IP address. This image closes both before the port ever accepts a request:

Databasus creates an administrator called admin with no password. The endpoint that sets that password is unauthenticated and stays open until somebody uses it, so on a bare install the first person to reach the VM becomes the administrator. This image sets a unique administrator password on first boot, over the loopback interface, and then verifies that the endpoint is closed.
Databasus allows open self-registration by default. Anyone reaching the VM could create a working account. This image turns self-registration off. You can turn it back on at any time in the web interface under Settings.

Nothing is baked into the image. Every VM generates its own administrator password, its own demo database password and its own AES-256 encryption key on first boot.

1. Deploy the VM

Launch the image from the Azure Marketplace. A Standard_B2s (2 vCPU, 4 GiB) is the recommended size and is what this guide assumes.

Open port 4005 to the networks that need the web interface, and open port 22 for SSH. Keep 4005 restricted to your own IP ranges where you can.

The bundled demo PostgreSQL is published on 127.0.0.1 only. The VM itself and the Databasus container can reach it, but the network never can, so there is no database port to firewall.

2. Sign in

The VM generated your administrator password. Read it over SSH:

sudo cat /root/databasus-credentials.txt

The file is 0600 root:root and contains the Databasus sign-in details and the demo database password.

Open http://<vm-ip>:4005/ in a browser. Sign in with the login admin and the password from that file.

Change the administrator password once you are in, under Settings.

3. Confirm the appliance is healthy

Check that both services and both containers are up:

systemctl is-active docker databasus databasus-firstboot
sudo docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Note the ports. Databasus is published on 0.0.0.0:4005, while the demo database is bound to 127.0.0.1:5432.

The application also answers a health endpoint and reports its version:

curl -s http://127.0.0.1:4005/api/v1/system/health -o /dev/null -w 'health: HTTP %{http_code}\n'
curl -s http://127.0.0.1:4005/api/v1/system/version

4. Verify the security posture

Confirm both protections yourself. None of these requests should succeed:

# A protected endpoint with no session must be refused.
curl -s -o /dev/null -w 'no session: HTTP %{http_code}\n' -m 15 \
  http://127.0.0.1:4005/api/v1/users/me
# Trying to seize the administrator account must be rejected.
curl -s -m 15 -X POST http://127.0.0.1:4005/api/v1/users/admin/set-password \
  -H 'Content-Type: application/json' \
  -d '{"password":"attacker-would-own-this-vm"}' echo
# Trying to self register must be rejected.
curl -s -m 15 -X POST http://127.0.0.1:4005/api/v1/users/signup \
  -H 'Content-Type: application/json' \
  -d '{"name":"Stranger","email":"stranger@example.invalid","password":"StrangerPass123"}' echo

You should see HTTP 401, admin password is already set and external registration is disabled.

Your own credentials, on the other hand, should work. This command reads the real password from the root-only file, so it is a genuine end-to-end check:

sudo bash -c 'PASS=$(grep "^DATABASUS_ADMIN_PASSWORD=" /root/databasus-credentials.txt | cut -d= -f2-); \
  TOKEN=$(curl -s -m 20 -X POST http://127.0.0.1:4005/api/v1/users/signin \
  -H "Content-Type: application/json" \
  -d "{\"email\":\"admin\",\"password\":\"$PASS\"}" | jq -r ".token"); \
  [ -n "$TOKEN" ] && [ "$TOKEN" != "null" ] || { echo "sign in FAILED"; exit 1; }; \
  echo "signed in, token issued"; \
  curl -s -m 20 http://127.0.0.1:4005/api/v1/users/me -H "Authorization: Bearer $TOKEN" | jq -r ".email"'

5. Look at the bundled demo database

The demo database is a real PostgreSQL 17, configured for Point-In-Time Recovery. Check its settings:

sudo bash -c 'export PGPASSWORD=$(grep "^DEMO_POSTGRES_PASSWORD=" /root/databasus-credentials.txt | cut -d= -f2-); \
  psql -h 127.0.0.1 -p 5432 -U postgres -d demo \
  -c "SHOW server_version" -c "SHOW wal_level" -c "SHOW summarize_wal"'

wal_level = logical and summarize_wal = on are what make Point-In-Time Recovery and PostgreSQL 17 incremental base backups possible. max_wal_senders and replication slots are configured too. The pg_hba.conf permits password-authenticated replication connections from the Databasus container.

The demo database itself starts empty. That is deliberate: the image ships no data of ours, so nothing from the build ever reaches your VM.

Give the database something to protect before you take your first backup:

sudo bash -c 'export PGPASSWORD=$(grep "^DEMO_POSTGRES_PASSWORD=" /root/databasus-credentials.txt | cut -d= -f2-); \
  psql -h 127.0.0.1 -p 5432 -U postgres -d demo -v ON_ERROR_STOP=1 -c \
  "CREATE TABLE IF NOT EXISTS sac_demo (id bigserial PRIMARY KEY, payload text NOT NULL, created_at timestamptz NOT NULL DEFAULT now());" -c \
  "INSERT INTO sac_demo (payload) SELECT md5(random()::text) FROM generate_series(1, 500);" -c \
  "SELECT count(*) AS demo_rows FROM sac_demo;"'

This creates a small table and puts 500 rows in it. The backup that you take in the next step then has real content and a measurable size.

6. Add a database and take a backup

In the web interface:

Create a workspace. A workspace groups databases, storages and notifiers.
Add a storage under the storage icon in the left rail. Local disk keeps backups on this VM's disk and needs no configuration. For anything you care about keeping, add S3, Azure Blob Storage or another off-box destination instead, so that a lost VM does not take the backups with it.
Click Add database, give it a name and choose PostgreSQL.
Choose the backup type. Logical runs a native dump. It is simple and good under about 50 GB.
Physical copies the cluster at file level and can stream write-ahead log data. That is what gives you Point-In-Time Recovery and a much lower recovery point objective. Choose Full + incremental + WAL for the full capability.
Enter the connection. For the bundled demo database, the host is demo-postgres, the port is 5432, the user is postgres and the password is the DEMO_POSTGRES_PASSWORD from your credentials file.

The host is demo-postgres, not 127.0.0.1. Databasus runs in a container and reaches the demo database by its service name on the internal network. 127.0.0.1 inside the container means the container itself.

When offered, accept create a replication only user. Databasus then stores a credential that can read your data but never modify it, so even a compromised Databasus cannot corrupt the database it protects.
Pick your storage, schedule and retention, and save.

Your backup configuration then looks like this.

Click Make backup right now on the Backups tab to run a backup immediately rather than waiting for the schedule.

A finished backup shows as Successful with its size and duration. That is the whole loop working: Databasus connected to the database, read it, wrote the backup to your storage and recorded it.

7. Turn on restore verification

A backup you have never restored is a hope, not a backup. Databasus can prove it. On the Verifications tab, you can have Databasus restore a backup into a temporary copy on a schedule, count the rows in every table and report the result.

Restore verification uses a verification agent. Add one under Settings, in the Verification agents section, and Databasus walks you through it. Until an agent is registered, the Verifications tab tells you so.

8. Point Databasus at your own databases

The demo database is only a starting point. To protect a real database, add it exactly as in step 6 and give Databasus a connection to it.

The database must be reachable from this VM. Allow the Databasus VM's address in the target database's firewall and, for a physical backup, in its pg_hba.conf.

Databasus supports PostgreSQL 14 to 18 for both physical and logical backups, and MySQL, MariaDB and MongoDB for logical backups.

Do two things on day one:

Send backups off this VM. Add S3 or Azure Blob Storage as a storage destination. Backups on the same disk as the thing being backed up do not survive losing the disk.
Turn on notifications. Email, Slack, Telegram, Discord and webhooks are all supported. A failure you are not told about is a backup you do not have.

Databasus encrypts backups with AES-256 when you enable encryption on a backup configuration, so an off-box destination stays useless to anyone who gets hold of it.

Keep a copy of the encryption key from /databasus-data somewhere safe. Without the key, those backups cannot be restored.

Where things live

/etc/databasus/compose.yaml: container definitions for both services
/etc/databasus/databasus.env: per-VM secrets, 0600 root:root
/root/databasus-credentials.txt: sign-in details, 0600 root:root
/usr/share/doc/sac/third-party-licences/: Databasus license and NOTICE

Useful commands:

sudo systemctl restart databasus
sudo docker logs --tail 50 databasus-databasus-1

Backups written to the Local disk storage live in the databasus_databasus_data Docker volume. So do Databasus' own database and encryption key.

Support

For help with this image, email sales@secureanycloud.com.

Databasus is free and open-source software licensed under the Apache License 2.0. "Databasus" is a trademark of Rostislav Dugin. SecureAnyCloud is not affiliated with, endorsed by, or sponsored by the Databasus project. PostgreSQL is a trademark of the PostgreSQL Community Association.

Deploy on Azure

Launch Databasus with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure