How do you actually back up and restore a Docker named volume, given that the data lives inside Docker-managed storage you can't directly browse from the host?

Run a temporary throwaway container that mounts both the named volume and a host directory (or another destination), and use it purely to copy data between the two — tar inside a helper container is the standard pattern for both backup (archive the volume's contents to a host path) and restore (extract a host-side archive back into a fresh named volume).

Docker deliberately abstracts named volume storage location away from the user (unlike a bind mount, which is just a host path you already know), which is exactly what makes named volumes portable and Docker-managed — but it means you can't just cp the data directly from the host filesystem the way you could with a bind mount. The standard workaround is using a container as the bridge between the volume and wherever you actually want the backup to live, since any container can mount a named volume regardless of where Docker physically stores it.

Backup: mount the volume plus a host output directory in a temporary container:

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

This starts a throwaway Alpine container, mounts the named volume read-only at /data (read-only, since a backup shouldn't be able to accidentally modify the source), mounts a host directory at /backup, archives the volume's contents, and exits — --rm cleans up the container immediately after, leaving only the archive on the host.

Restore: reverse the mounts, extract into a fresh (or existing) named volume:

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

Restoring into a newly created volume (rather than overwriting the original in place) is a deliberate choice for anything beyond a quick test — it lets you verify the restored data is correct before pointing your actual application at it, rather than committing to the restore before confirming it worked.

This same pattern generalizes to volume-to-volume copies, not just volume-to-host, by mounting two named volumes in the same helper container instead of one volume and one host path — useful for cloning a volume's data into a new one without a host-side intermediate step at all.

• A throwaway helper container mounting both the named volume and a destination is the standard way to move data in or out of Docker-managed volume storage.
• Mount the source read-only during backup, so the backup process itself can't accidentally modify the data it's archiving.
• Restore into a new volume rather than overwriting in place when possible, so you can verify correctness before committing your application to the restored data.
• The same helper-container pattern works for volume-to-volume copies, not just volume-to-host backup/restore.

• Docker Docs: Back up, restore, or migrate data volumes