DBackup
Database integration

MySQL backups, consistent and encrypted.

DBackup dumps every database from one consistent snapshot, with its routines and events unless you turn them off. It encrypts the dumps with AES-256-GCM when the job has a key and keeps them on the storage you choose.

Start in five minutesRead the MySQL guide
Open source under GPL-3.0 · runs on your own server
shop-mysqlRunning
  1. ConnectDirect to mysql:3306
  2. Dumpmariadb-dump --single-transaction --routines --events --databases shop
  3. EncryptGzip and AES-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.
Tested with 5.7 and 9.1
MySQL 5.7 to 9
Written by mariadb-dump
Plain SQL
Over SSH, the dump runs on your server
Direct or over SSH (beta)
Pick databases and give them new names
Restore in the app

How a MySQL 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. 1Dump--single-transaction reads the InnoDB tables of each database at one point in time, without blocking writes.
  2. 2CompressDBackup can compress each dump with Gzip or Brotli. The SQL inside stays plain text.
  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.

Three switches, and a check per database

Under Options, the source decides what goes into the dump. All three switches are on unless you turn them off.

The password reaches the dump tool in a temporary file that only its owner can read, never on the command line.

  • Consistent snapshot--single-transactionReads InnoDB tables at one point in time without blocking writes. Off, the tables of each database are locked while it is dumped.
  • Stored procedures and functions--routinesDumps the routines of each database with its tables.
  • Events--eventsDumps the scheduled events of each database.

Before each dump DBackup checks what the login may read. Where it may not read the events or the body of a routine, that database is dumped without them, with a warning on the run.

Every database in one archive

Pick some databases of a server, or leave the pick empty for all of them without the system schemas. Each gets its own dump in one TAR with a manifest and an index of checksums.

  • With an empty pick, the next run takes a new database along.
  • Restore one database under a new name, and the app rewrites its USE and CREATE DATABASE lines on the way in.
  • Unencrypted, the archive opens with tar -xf, and every dump is an SQL file, compressed with Gzip or Brotli when the job compresses.
  • TARshop-mysql_2026-10-08_03-00-00.tar182 MB
  • { }manifest.json
  • DIRdatabases/
  • DBshop.sql.gz96 MB
  • DBblog.sql.gz41 MB
  • DBcrm.sql.gz45 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-mysql_2026-10-08_03-00-00.tar ./restored databases/shop$ mariadb -u root -p < ./restored/databases/shop.sql

Get it back without DBackup

Every dump is plain SQL made with --databases, so it creates and selects its own database. The Recovery Kit decrypts and unpacks it, and the mariadb client, the one DBackup restores with, reads it 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

  mysql:
    image: mysql:9
    environment:
      - MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

MySQL questions

MySQL 5.7 and newer. The integration tests run against 5.7 and 9.1. An older server gets a warning, and the dump still runs.

In the Docker image it runs mariadb-dump, MariaDB's version of mysqldump, which dumps MySQL as well. Over SSH it takes mariadb-dump or mysqldump, whichever the server has.

Not with the consistent snapshot, which is on by default. It reads InnoDB tables at one point in time while writes carry on. Turn it off, and the tables of each database are locked while it is dumped.

SELECT, SHOW VIEW, TRIGGER and EVENT, and LOCK TABLES when the snapshot is off. A restore that has to create a database asks for an admin login once.

Yes. Every dump is a plain SQL file. The Recovery Kit gets it out, encrypted or not, and unpacks it, with nothing but Node.js. Then feed it to the mariadb client, the one DBackup restores with.

Other databases

All integrations
MariaDBVersions 10 and 11PostgreSQLVersions 12 to 18MongoDBVersions 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 MySQL backup runs tonight.

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

Start in five minutesView on GitHub