How do you back up and restore data in a Docker volume?

Backing up a volume

docker run --rm \
  -v my-app-data:/source:ro \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/my-app-data-backup.tar.gz -C /source .

Breaking this down:

• -v my-app-data:/source:ro — mounts the volume you want to back up, read-only (:ro), into a temporary container, so the backup process can't accidentally modify the live data while reading it.
• -v $(pwd):/backup — a bind mount, giving the temporary container access to your current host directory, so the resulting archive ends up somewhere you can actually access it afterward (outside the ephemeral container).
• alpine — a minimal, throwaway image, chosen purely because it includes tar and almost nothing else needed for this one-off task.
• tar czf /backup/my-app-data-backup.tar.gz -C /source . — the actual backup command, compressing everything in /source (the mounted volume) into a single archive file, written into /backup (the bind-mounted host directory).
• --rm — automatically removes this temporary container once the command finishes, since it has no ongoing purpose beyond this one backup operation.

Restoring from a backup

docker volume create my-app-data-restored

docker run --rm \
  -v my-app-data-restored:/target \
  -v $(pwd):/backup \
  alpine \
  tar xzf /backup/my-app-data-backup.tar.gz -C /target

The reverse process: create a fresh (or existing, if genuinely restoring in place) volume, then mount it as the extraction target. Unpack the previously created archive into it via the same kind of temporary, throwaway container.

Why this pattern works: volumes aren't tied to any specific "owning" container

The key insight making this whole technique possible is that a named volume isn't permanently bound to whichever container originally used it. Any container can mount it, including a completely unrelated, temporary one whose only job is to run a backup/restore command. This is exactly the same underlying property that makes volumes useful for migrating data between different application versions, or even entirely different applications. It works as long as both sides agree on the expected data format inside the volume.

Database-specific backup tools are usually still the better choice for real databases

docker exec my-postgres pg_dump -U postgres mydb > backup.sql

For an actual running database, the database's own native backup tooling (pg_dump, mysqldump, and equivalents) is generally a better approach than a raw filesystem-level tar of the volume. A live database's on-disk files can be in an inconsistent, mid-write state if archived directly while the database is running, unless it's stopped first, or the tool specifically supports safe hot-backup snapshotting. A proper database dump tool, by contrast, guarantees a consistent, valid backup by working through the database's own transactional guarantees, rather than copying raw files.

Automating this as a scheduled task

# A cron job, or a scheduled CI/CD pipeline step, running the backup command
# above on a regular schedule, pushing the resulting archive to durable,
# off-host storage (cloud object storage, a dedicated backup server) --
# never leaving backups only on the SAME host as the live data.

This mirrors the same principle covered in the SQL/Databases and Kubernetes stacks' backup questions. Backups must be automated on a regular schedule, stored somewhere genuinely separate from the live data (so a single host failure can't destroy both simultaneously), and periodically tested by actually performing a restore. An untested backup isn't a real backup, regardless of which specific technology or command produced it.