HomeFeaturesCompareBlogChangelogDeployGitHubGet started
Blog
6 min read

Easily back up a Docker database

Use LazyBackup’s database dump source to pull Postgres, MySQL, or MariaDB from a container into a scheduled .sql.gz—without stopping the DB.

howtodockerdatabase
New backup form configured as a Postgres database dump from a server

Tar’ing a Docker volume is fine for files. For a live database, you want a logical dump: pg_dump or mysqldump while the engine is running. LazyBackup treats that as a first-class source type—Database dump—so you pick the server, the engine, and (optionally) the container, then land a .sql.gz on this host, another server, or S3.

What you’ll set up

  1. A server in LazyBackup with SSH key auth (needed for transfers)
  2. A backup job: From = that server, Source type = Database dump
  3. Client mode: Docker exec (into the DB container) or Native tools on the host
  4. A destination path or S3 prefix, plus a cron schedule
From server database dump to this host path
From → To with Source type set to Database dump.

Step 1 — Add the server

Under Servers, add the host where Docker (or the native client) runs. Test the connection. Transfers need SSH key auth; password-only is enough to poke around, not to pull dumps.

Servers list in LazyBackup
One SSH endpoint per machine you dump from or push to.

Step 2 — New backup → Database dump

Create a backup. Set From to Server, pick the host, then change Source type to Database dump. Destination can stay This host (e.g. /backups/…), another server, or S3.

  • Engine — PostgreSQL, MySQL, or MariaDB
  • Client — Native (pg_dump / mysqldump on the host) or Docker exec (into the container)
  • Credentials — database name, user, password (and host/port for native)
Database connection fields for PostgreSQL dump
Engine, client, and credentials. Use Test connection before you rely on cron.

Docker exec mode (the easy path)

If Postgres/MySQL runs in Docker on that server, choose Client → Docker exec. LazyBackup lists running containers and can fill engine, user, password, and database name from common env vars (POSTGRES_*, MYSQL_*, MARIADB_*). It runs pg_dump or mysqldump inside the container, writes a temp .sql.gz, then transfers that file to your destination—no dump SQL streamed through SSH stdout.

From:  Server → Database dump → Docker exec → your DB container
To:    This host / Server / S3 prefix
Out:   something like app_2026-08-11_….sql.gz

Step 3 — Schedule and retention

Set a cron expression (runs in the app timezone from Settings). For dump folders, enable file retention so old .sql.gz files age out while you keep a minimum count. Versioning is useful for path trees; for single dump files, retention is usually enough.

Backup history with successful runs
After a run, History shows status, size, and logs—and restore when you need it.

Restore later

From History, restore loads the dump into the target engine (local artifact, or pull from S3, Bro, or an SSH destination with a key first). Same idea as the dump: native client or docker exec on the destination side of the restore flow. You can restore onto a different host from the History server picker.

Quick checklist

  • SSH key on the source server
  • Source type = Database dump (not Docker volume)
  • Docker exec if the DB lives in a container
  • Test connection once
  • Cron + retention so disks don’t fill forever

Ready to try it?

Docker one-liner on the home page, or clone the repo.

DeployGitHub