On a Mac using Docker Desktop, back up a Compose named volume by mounting it into a temporary container and writing a tar archive into a folder on your Mac. Check the volume name, stop services that write to it, make the archive, and confirm the file exists before removing containers. A regular docker compose down keeps named volumes; docker compose down --volumes removes eligible project volumes, so do not run it until the backup is complete.

1. Identify the Compose volume and its mount path

In Terminal, go to the directory containing the project’s Compose file. Find the service mount, such as db-data:/var/lib/postgresql/data, and its matching top-level declaration under volumes:. The left side, db-data, is the Compose key; the container path after the colon is where the application sees the data. Compose may create the actual Docker volume with a project prefix, while a configured name: can give it a custom name. Docker’s Compose volume reference describes those naming rules.

List volumes used by the current Compose project:

docker compose volumes

Use that output and the Compose file to identify the exact Docker volume. If the project uses multiple Compose files, profiles, or a custom project name, use the same options when inspecting it as when the stack was started. Do not guess the actual volume name from the YAML key alone. docker volume ls can show all Docker volumes, but it may include unrelated projects.

2. Stop writes before making the archive

A filesystem archive is not necessarily a consistent database backup if the database is changing while files are copied. First stop the application cleanly; for a Compose stack, docker compose stop stops its services while retaining containers and volumes. If the database has an application-specific dump or backup procedure, use it when transaction-level consistency matters, then also make a volume archive if you need a file-level copy.

Avoid docker compose down --volumes at this stage. Compose documents that down removes the project’s containers and networks by default, while --volumes also removes eligible named and anonymous volumes. External volumes are not removed by down. Docker’s compose down reference explains the distinction.

3. Create a tar backup in a Mac folder

The following example assumes the actual Docker volume is named myproject_db-data. Replace that value with the exact name you identified. It saves db-data-backup.tar in the current Mac directory. Docker Desktop runs the Docker Engine inside a Linux VM, so a named volume’s data is managed by Docker; this method copies it through a temporary container rather than relying on a Linux VM storage path. Docker’s volume guide documents the helper-container and tar approach, and Docker Desktop’s Mac settings documentation describes the Linux VM and host file sharing.

volume_name='myproject_db-data'
backup_dir="$PWD"
backup_file='db-data-backup.tar'

docker run --rm \
  --mount "type=volume,source=$volume_name,target=/source,readonly" \
  --mount "type=bind,source=$backup_dir,target=/backup" \
  alpine sh -c 'tar -C /source -cf "/backup/'"$backup_file"'" .'

The archive is written to the directory represented by $PWD, so choose a location with enough free space before running the command. The volume is mounted read-only in the helper container to prevent accidental changes during copying; this does not itself stop other containers from writing, which is why stopping writers first matters. The command requires Docker Desktop to be running and the Mac folder to be accessible for bind mounts. If the mount fails, check Docker Desktop’s file-sharing access for the folder.

Check that the archive exists and has a plausible nonzero size:

ls -lh "$backup_file"

This confirms a file was created, not that its contents form a restorable application backup. Keep the archive somewhere outside the Docker-managed volume, and consider copying it to your normal backup destination before deleting data.

4. Remove containers only after verifying your target

When the archive is in place, remove the project’s containers with:

docker compose down

This leaves the named volume in place by default. If your intent is also to delete the volume, first verify the project and volume names again, then use docker compose down --volumes only when you are ready to remove that data. A custom-named or external volume can have different lifecycle behavior; check the Compose definition and Docker’s command reference rather than assuming the option affects every volume.

Restore considerations

Docker’s documented volume workflow restores a tar archive by mounting the destination volume and extracting the archive into it. For database files, restore into a fresh or intentionally cleared volume while the database service is stopped, and follow the database image’s ownership and initialization requirements. Do not extract over a volume containing data you still need: existing files can collide with the archive, and a tar extraction is not a safe merge strategy. If you need a database-consistent recovery point, use the database’s own backup and restore process as well as, or instead of, a raw file archive.

Sources