DBackup
Database integration

PostgreSQL backups, self-hosted and encrypted.

DBackup runs pg_dump on a schedule, encrypts the dumps with AES-256-GCM when the job has a key and keeps them on the storage you choose. Directly or over SSH, with the restore in the same app.

Start in five minutesRead the PostgreSQL guide
Open source under GPL-3.0 · runs on your own server
shop-postgresRunning
  1. ConnectDirect to postgres:5432
  2. Dumppg_dump -F c -Z zstd:3 -d shop
  3. EncryptAES-256-GCM
  4. UploadHetzner Object Storage
  5. Retention7 daily, 4 weekly, 12 monthly
  6. NotifyDiscord · #backups
With an encryption profile, every dump is encrypted with AES-256-GCM before it leaves your server.
pg_dump 18 ships in the image
PostgreSQL 12 to 18
Restored with pg_restore
Custom format
Over SSH, pg_dump runs on your server
Direct or over SSH (beta)
Pick databases and give them new names
Restore in the app

How a PostgreSQL backup runs

Four steps, each one a tool or a format you could use yourself. DBackup runs them on a schedule and tells you when one fails.

  1. 1Dumppg_dump -F c writes a custom-format dump of each database, one after the other.
  2. 2CompressGzip, LZ4 or Zstd inside pg_dump, at a level you pick. Or none, and DBackup can compress the dump instead.
  3. 3EncryptAES-256-GCM with the key of an encryption profile, for each dump on its own. Inside, the dump stays what the tool wrote.
  4. 4StoreUploaded to one or several of the 13 destinations, each with its own retention, from a simple count to daily, weekly, monthly and yearly.

Native compression, picked per job

The job decides how pg_dump compresses, with a level between faster and smaller. While it does, DBackup leaves the dump as it is, so nothing is compressed twice.

The job form reads the version of your server and offers LZ4 from PostgreSQL 14 and Zstd from 16.

Zstd, small and fastSmall files at a good speed. Levels above 19 need a lot of memory.
FasterLevel 3, the defaultSmaller
122
$ pg_dump -F c -Z zstd:3 -d shop

Every database in one archive

Pick some databases of a server, or all of them. Each gets its own dump, and all of them land in one TAR with a manifest and an index of their checksums.

  • Leave the pick empty and every run finds the databases again, new ones included.
  • Restore one database and leave the others alone, under its own name or a new one.
  • Unencrypted, the archive opens with tar -xf, and the dumps inside are plain pg_dump files.
  • TARshop-postgres_2026-10-08_03-00-00.tar1.3 GB
  • { }manifest.json
  • DIRdatabases/
  • DBshop.dump412 MB
  • DBcrm.dump268 MB
  • DBanalytics.dump640 MB
  • { }index
The layout of an unencrypted archive. In an encrypted one the entries carry neutral names.
Any computer with Node.js
$ node dbackup-recover.js --extract shop-postgres_2026-10-08_03-00-00.tar ./restored databases/shop$ createdb shop$ pg_restore --no-owner -d shop ./restored/databases/shop.dump

Get it back without DBackup

Every dump is what pg_dump wrote. Keep the Recovery Kit somewhere DBackup cannot reach, and any machine with Node.js and pg_restore 18 brings the data back.

The Recovery Kit from the Vault is a script and your key. It decrypts and unpacks a dump and checks its SHA-256 before it writes the file.

Why we built it this way

Running in five minutes

DBackup is one container. Put it next to your database, give it a login and add the first job.

docker-compose.yml
services:
  dbackup:
    image: skyfay/dbackup:latest
    restart: always
    ports:
      - "3000:3000"
    environment:
      - ENCRYPTION_KEY=${ENCRYPTION_KEY}          # openssl rand -hex 32
      - BETTER_AUTH_SECRET=${BETTER_AUTH_SECRET}  # openssl rand -base64 32
      - BETTER_AUTH_URL=https://localhost:3000
    volumes:
      - ./data:/data

  postgres:
    image: postgres:18
    environment:
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

PostgreSQL questions

PostgreSQL 12 to 18. The image ships pg_dump from PostgreSQL 18, which reads every older server in that range. Over SSH, the pg_dump on your server does the work.

No. DBackup runs pg_dump for each database and never pg_dumpall, so roles and tablespaces are not in the backup. A restore leaves out owners and grants, so the restored objects belong to the login that restores them.

Yes, over SSH, which is in beta. DBackup logs into the server, runs pg_dump there and streams the dump back. pg_dump, pg_restore and psql have to be installed on that server.

No. Reading the data is enough. From PostgreSQL 14 the pg_read_all_data role covers every database, on older servers you grant CONNECT and SELECT per database.

Yes. The Recovery Kit gets the dumps out, encrypted or not, with nothing but Node.js. pg_restore reads them back, version 18 for dumps from the Docker image, since pg_restore never reads a dump from a newer pg_dump.

Other databases

All integrations
MySQLVersions 5.7 to 9MariaDBVersions 10 and 11MongoDBVersions 4 to 8RedisVersion 2.8 and newer

From the blog

Why We Built DBackup: No Vendor Lock-In by DesignEvery DBackup backup is a standard database dump encrypted with open AES-256-GCM - here's why that matters and how the Recovery Kit works.Read the post

Your first PostgreSQL backup runs tonight.

One container, one compose file and a job. Free and open source.

Start in five minutesView on GitHub