Backing Up Docker Containers and Volumes

What This Article Covers

• Why backups matter for Docker containers
• Manual and automated volume backup strategies
• Protecting Compose configurations and environment variables
• Encryption and offsite storage
• Restoration procedures and common pitfalls

Introduction: Backing Up Docker Containers and Volumes

Docker containers themselves are stateless. Your data, configurations, and workloads live in volumes, bind mounts, and Compose files. Skip backups, and a hardware failure, accidental deletion, or botched update wipes everything out. A solid backup strategy covers volumes, Compose files, .env files, images, and regular offsite copies.

This article walks through structuring, automating, and restoring Docker backups.

Key Terminology

• Volume backup: Backing up a Docker volume.
• Bind mount backup: Backing up a directory mounted from the host.
• Compose backup: Backing up the YAML file and environment variables.
• Offsite: Storage outside your primary server.
• Snapshot: Point-in-time copy of your system.
• Restore: Recovery from a backup.
• Retention: How long backups are kept.
• rsync: Tool for incremental backups.

What Needs Backing Up?

Component	Reason
Docker Volumes	Contain databases, models, configurations.
Bind Mounts	Persistent data stored on the host.
compose.yaml	Defines your entire stack.
.env Files	Secrets and configuration values.
Docker Images	Enables fast recovery without re-downloading.
Container Settings	Labels, networks, environment variables.

Manual Volume Backup

The simplest approach uses a temporary container to mount the volume:

docker run --rm -v ollama-data:/data -v $(pwd):/backup alpine tar -czf /backup/ollama-data.tar.gz -C /data .

This creates a compressed archive in your current directory.

Manual Restore

docker run --rm -v ollama-data:/data -v $(pwd):/backup alpine tar -xzf /backup/ollama-data.tar.gz -C /data

Make sure the target volume exists beforehand, or create it first.

Backing Up Bind Mounts

Bind mounts are standard directories on your host. Back them up with rsync or tar:

rsync -av /opt/ollama-data /backup/ollama-data/

Compose Files and Secrets

Keep all Compose projects in a central directory to simplify backups:

rsync -av /opt/docker-compose/ /backup/docker-compose/

Store compose.yaml, .env files, and configuration here. Since .env files contain secrets, encrypt them or apply special protection.

Automated Backups

A Bash script for regular backups:

#!/bin/bash
set -e

BACKUP_DIR="/backup/docker/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_DIR"

# Volumes
for volume in ollama-data pg-data open-webui-data; do
  docker run --rm -v "$volume":/data -v "$BACKUP_DIR":/backup alpine \
    tar -czf "/backup/$volume.tar.gz" -C /data .
done

# Compose projects
rsync -av /opt/docker-compose/ "$BACKUP_DIR/docker-compose/"

# Logs
echo "Backup created: $BACKUP_DIR" >> /var/log/docker-backup.log

Cron Job

0 3 * * * /usr/local/bin/backup-docker.sh >> /var/log/docker-backup.log 2>&1

Offsite Storage and Encryption

Backups shouldn’t live only on your primary system. Options include:

• External hard drives
• NAS or Synology appliances
• Cloud storage via rclone
• S3-compatible object storage
• Tailscale node on a remote network

Encrypt with restic:

restic -r /mnt/backup-repo backup /backup/docker
restic -r /mnt/backup-repo snapshots

Backing Up Active Databases

Back up databases consistently. A database dump is safer than raw file copying:

docker exec postgres pg_dumpall -U admin > backup.sql

For SQLite, copy the database file directly as long as no active transaction is running.

Restoring a Full Stack

1. Install Docker on the new host
2. Transfer backups to the new host
3. Restore volumes
4. Copy Compose projects to the correct location
5. Run docker compose up -d

Backup Strategies

• 3-2-1 Rule: Three copies, two media types, one offsite.
• Incremental: Back up only changed data.
• Pre-update Snapshots: Snapshot before major updates.
• Test Restores: Regularly verify backups actually work.
• Monitoring: Log backup success and alert on failures.

Common Pitfalls

• Skipping container backups: Right call, they’re stateless. Volumes are what matter.
• Copying active databases: Creates inconsistent backups.
• Unencrypted secrets: .env files hold passwords.
• Poor retention policy: Old backups accumulate and fill storage.
• Untested restores: Backups work fine, restores fail when you need them.
• Local-only backups: Hardware failure means total data loss.

Further Reading and Resources

• BotServ.de Docker Volumes
• BotServ.de Docker Compose
• BotServ.de Proxmox Backups and Restore
• BotServ.de Secret Management

FAQ: Docker Backups

Should I back up entire containers? No, back up volumes and Compose files. Recreate containers from scratch.

How often should I back up? Daily for active data, weekly for static configurations.

Are Docker volume backups portable? Yes, if you restore them to a compatible target system.

How do I secure secrets? Encrypt them or store them in a password manager.

What’s the 3-2-1 rule? Three copies, two different storage media, one copy offsite.

Sources and Further Reading

• Docker Volumes Backup: https://docs.docker.com/storage/volumes/#back-up-restore-or-migrate-data-volumes
• restic: https://restic.net/
• rsync: https://rsync.samba.org/

Summary: Backing Up Docker Containers and Volumes

Docker backups focus on volumes, bind mounts, Compose files, and environment variables. Manual backups with tar and rsync take minutes. Automated backups via cron are essential for production. Consistent database dumps, encrypted secrets, offsite storage, and periodic restore tests round out a robust strategy. Following the 3-2-1 rule gives you much better protection against data loss.