DBackup
NewVersion 4.0, with a redesigned interface

Backups for PostgreSQLand the files that belong to them.

Self-hosted backup automation with encryption, compression and smart retention. One Docker image, no agent, no lock-in.

Get startedOpen source
Nextcloud nightlyIncremental
MariaDB and /srv/nextcloud to Hetzner and R2
Running
Dump the database nextcloud0 %
  1. Dump the database nextcloud0 %
  2. Collect config and data over SFTP
  3. Compress with Brotli
  4. Encrypt with AES-256-GCM
  5. Upload to Hetzner
  6. Upload to Cloudflare R2
database engines
10
storage adapters
14
notification channels
9
AES-GCM encryption
256 bit

Integrations

MySQLMariaDBPostgreSQLMongoDBSQLiteRedisValkeyMicrosoft SQL ServerAzure SQL Database (Beta)Firebird (Beta)DiscordSlackMicrosoft TeamsTelegramGotifyntfyWebhookSMS (Twilio)Email (SMTP)
Local FilesystemAmazon S3S3 CompatibleCloudflare R2Hetzner Object StorageGoogle DriveDropboxMicrosoft OneDriveSFTPFTP/FTPSWebDAVSMB/SambaRsyncDocker Volumes (Beta)
All 33 integrations
Features

Everything a backup needs, in the interface you will actually use.

One color per task

Blue adds, violet edits, turquoise picks, amber warns. Every dialog tells you what it is about to do.

New job
Step 2 of 4 · Databases
shop
MariaDB · prod
2.1 GB
analytics
MariaDB · prod
840 MB
staging
MariaDB · prod
310 MB
wordpress
MariaDB · prod
96 MB
2 of 4 picked2.9 GB
BackNext

Everything is one keystroke away

Try it. Type to filter.

  • New jobC
  • Restore a backupR
  • Edit retention templateE
  • Pick a destinationP
  • Run Postgres nightly nowEnter
  • Open Database ExplorerG D
  • Show failed runsG H

Every day, accounted for

A backup calendar that shows gaps before you need them.

CompletedPartialFailed

AES-256-GCM

Encrypted before it leaves the host. Restorable with the Recovery Kit alone.

Alerts where you are

9 channels, per job or system wide.

Retention, reused

GFS templates shared by every job.

Daily
7
Weekly
4
Monthly
12

Built for teams

SSO, roles, passkeys and a REST API.

No vendor lock-in

Your backup is a file. Open it without us.

Standard dumps and plain TAR archives, sealed with open AES-256-GCM. The format is specified byte by byte.

Read the format specWhy no deduplication
~/restore
$ tar -xf nightly_2026-09-27.tar $ ls nextcloud.sql files/ manifest.json $ mysql nextcloud < nextcloud.sql Restored without DBackup running
Quick start

Running in two minutes.

services:
  dbackup:
    image: skyfay/dbackup:latest
    restart: always
    ports:
      - "3000:3000"
    environment:
      - ENCRYPTION_KEY=  # openssl rand -hex 32
      - BETTER_AUTH_URL=https://localhost:3000
      - BETTER_AUTH_SECRET=  # openssl rand -base64 32
    volumes:
      - ./data:/data
      - ./backups:/backups
services:
dbackup:
image: skyfay/dbackup:latest
restart: always
ports:
- "3000:3000"
environment:
- ENCRYPTION_KEY= # openssl rand -hex 32
- BETTER_AUTH_URL=https://localhost:3000
- BETTER_AUTH_SECRET= # openssl rand -base64 32
volumes:
- ./data:/data
- ./backups:/backups
Two secrets to fill inMake them here, or with openssl as the comments say.
Step 1 of 3 · Fill in both secrets

Questions

Something missing? Ask on Discord.

Yes. Every backup is a standard database dump encrypted with open AES-256-GCM. With the key from your Recovery Kit and a standalone Node.js script, you can decrypt and restore without DBackup running at all.

MySQL, MariaDB, PostgreSQL, MongoDB, SQLite, Redis, Valkey, Microsoft SQL Server, Azure SQL Database (beta), and Firebird (beta), with more engines added regularly. See every integration.

Yes. Any storage adapter can serve as a directory source - local paths, SFTP, SMB, FTP, WebDAV, S3, Google Drive, Dropbox, OneDrive, rsync over SSH, or Docker volumes read through the daemon. Files and databases can share one job, so the dump and the data directory that belongs to it land in the same archive and the same restore point. There is no agent to install: DBackup reads whatever those protocols reach. That agentless design is also its limit - a full run pulls the tree to the DBackup host and stages it there before packing, so it wants roughly twice the source size in free space and every byte crosses the network twice. It is built for the files that belong to the applications you already back up databases for, not for bulk media libraries; for those, restic or Borg run on the machine itself and are the better tool.

Yes, currently in beta. Pick the volumes from a list of what the Docker daemon can see, locally through its socket or on another host over SSH, and DBackup mounts them into a short-lived helper container to read them. Containers holding a selected volume are stopped for the read and started again right afterwards, per volume rather than for the whole job, and you can switch that off for data that is safe to copy live. Restoring goes back into the same volume or into a new one, though directory permissions and empty directories are not carried back yet, which is what keeps it in beta.

Not globally, and that is a deliberate trade. Incremental backups store whole changed files and reference unchanged ones in earlier archives of the same chain, so every archive stays a plain TAR you can open with tar -xf or a documented format one Node.js script reads. A chunk store would save more space but would make the backup a repository only its own tool can open - which is the lock-in DBackup exists to avoid.

No. DBackup is self-hosted only, distributed as a single Docker image you run on your own infrastructure.

GPL-3.0. The source code is fully open and available on GitHub.

Yes. Multi-destination jobs upload each backup to several storage adapters at once for redundancy or off-site copies.

Stop hoping last night's
backup worked.

Free and open source under GPL-3.0. Yours to run.

Get startedJoin the Discord