Application-Aware Backups for Dockerized Databases

Running a database in Docker changes where you run the tools, not what the tools are. The restore-winning habit is keeping backups a first-class citizen of the container design: dump inside the container with its own client, copy the archive out, and rehearse restores into a fresh disposable container. Blindly tarring a named volume while the engine writes to it produces archives that pass the "it exists" check and fail the "it restores" check.

Dump with the container's own client

The image already contains pg_dump or mysqldump, so use it via docker exec. Pointing at 127.0.0.1 keeps the traffic inside the container network and off the public path.

docker exec mydb   pg_dump --format=custom --compress=9   --dbname=postgresql://app_user@127.0.0.1/appdb   --file=/tmp/appdb.dump
docker cp mydb:/tmp/appdb.dump /var/backups/appdb.dump
docker exec mydb rm /tmp/appdb.dump

For MySQL or MariaDB the pattern is the same, with the root password pulled from inside the container environment:

docker exec mydb sh -c   'exec mysqldump --single-transaction --quick -uroot -p"$MYSQL_ROOT_PASSWORD" appdb'   | gzip -9 > /var/backups/mysql/appdb.20260801.sql.gz

Because the archive leaves through stdin, no temporary file accumulates inside a container layer.

Check health before you dump

Dump only when the container is running and the database is ready. A container that restarted into recovery mode will happily dump a half-empty state.

#!/usr/bin/env bash
# /usr/local/bin/docker_db_backup.sh
set -euo pipefail
CONTAINER=mydb
STATUS=$(docker inspect --format '{{.State.Status}}' $CONTAINER)
[ "$STATUS" = "running" ] || exit 1
docker exec $CONTAINER pg_isready -U app_user 2>/dev/null || exit 1
docker exec $CONTAINER   pg_dump -Fc -U app_user appdb   > /var/backups/appdb.pipe.dump

Verify with the same image the restore will use

Restores on the box are performed by a database image's client, so verify with that image too. Mount the archive directory read-only and list it:

docker run --rm -v /var/backups:/b postgres:16   pg_restore --list /b/appdb.pipe.dump >/dev/null

Restore into a disposable container

The drill: launch a throwaway container from the same image, load the archive, and smoke-test with one query. When it passes, delete the container and the circle closes.

docker run -d --name appdb-restore -e POSTGRES_DB=appdb postgres:16
docker exec -i appdb-restore   pg_restore -U postgres -d postgres < /var/backups/appdb.pipe.dump
docker exec appdb-restore psql -U postgres   -c 'SELECT count(*) FROM orders;'
docker rm -f appdb-restore

Takeaway

Docker does not change what a database backup needs: a consistent dump via the right client, verification with the same toolchain, and a disposable restore target. Run the dump through docker exec, keep the archive out of the container's writable layer, and drill a restore into a fresh container on the same host. Netbay Linux VPS instances support Docker out of the box — start your container stack at netbayhosts.in.