Tudásbázis

Docker's isolation is convenient, but it changes how backups work — data lives in named volumes and bind mounts, not in a location you'd back up with a generic file backup script by default. This guide covers backing up Docker-based applications completely.

What Needs to Be Backed Up in a Docker Deployment

• Named volumes (database data, uploaded files)
• Bind-mounted directories
• docker-compose.yml and any associated configuration files
• .env files (handle securely due to secrets)

Listing All Volumes

docker volume ls

Backing Up a Named Volume

docker run --rm \
  -v myapp_db_data:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/db_data-backup.tar.gz /data

This mounts the volume into a temporary Alpine container just to create the tar archive, without needing to stop the actual running service.

Backing Up Multiple Volumes for a Full Compose Project

sudo nano /usr/local/bin/backup-docker-volumes.sh

#!/bin/bash
TIMESTAMP=$(date +%F)
BACKUP_DIR="/var/backups/docker"
mkdir -p "$BACKUP_DIR"

for VOLUME in $(docker volume ls -q); do
    docker run --rm \
      -v "$VOLUME":/data \
      -v "$BACKUP_DIR":/backup \
      alpine tar czf "/backup/${VOLUME}-${TIMESTAMP}.tar.gz" /data
done

find "$BACKUP_DIR" -type f -mtime +7 -delete

Backing Up Database Containers Properly

For database containers, use the database's own dump tool rather than a raw file copy, ensuring a consistent backup rather than potentially capturing mid-write data:

docker exec mysql-container mysqldump -u root -pPASSWORD --all-databases > db-backup.sql

Backing Up docker-compose.yml and Configuration

tar czf compose-config-backup.tar.gz docker-compose.yml .env

Restoring a Named Volume

docker volume create myapp_db_data
docker run --rm \
  -v myapp_db_data:/data \
  -v $(pwd):/backup \
  alpine sh -c "cd /data && tar xzf /backup/db_data-backup.tar.gz --strip 1"

Full Disaster Recovery for a Docker Deployment

1. Install Docker on the new server — see How to Install Docker Engine on Ubuntu & Debian
2. Restore docker-compose.yml and .env
3. Restore each named volume from backup
4. Run docker compose up -d
5. Verify all containers are healthy: docker compose ps

Automating with Off-Site Sync

Combine the volume backup script with an off-site upload step, same pattern as How to Set Up Automated VPS Backups:

rsync -avz /var/backups/docker/ user@backup-server:/backups/docker/

Common Errors

Backed-up volume is empty — verify the volume name is correct (docker volume ls) and that the container is actually writing data to that volume, not to its own internal writable layer instead.

Restore results in permission errors — some images expect specific file ownership inside volumes; verify against the original container's expectations, adjusting with chown inside a temporary container if needed.

Best Practices

• Use the database's native dump tool for database containers, not just a raw volume copy
• Back up docker-compose.yml and .env alongside volumes — data alone isn't a complete backup
• Test a full restore on a separate test server periodically

Related Articles

• Docker Volumes: Persisting Data
• How to Set Up Automated VPS Backups (rsync, cron & Off-Site Storage)
• How to Back Up and Restore MySQL/MariaDB Databases