Mastering Docker Persistent Storage: Volumes, Bind Mounts, and Tmpfs Explained

Data stored in a container’s layer is not persistent: it disappears when the container is removed, is hard for host processes to access, and incurs performance overhead due to the storage driver.

Docker offers three ways to achieve persistent data storage:

volumes : Managed by Docker in a directory on the host filesystem (e.g., docker volume create). Volumes survive container removal, can be shared read‑write or read‑only among multiple containers, and are the recommended method for persistent data.

bind mount : Maps any host directory or file into a container. Non‑Docker processes can modify the data, and Docker will create the host directory if it does not exist when using -v or --volume.

tmpfs mount (Linux only): Stores data in host memory; it is not written to disk and disappears when the container stops, making it suitable for temporary or sensitive data.

volumes

If a volume is not explicitly created, Docker creates it on first mount and keeps it after the container stops. Deleting a volume requires an explicit command.

When mounting an empty volume onto a directory that already contains files, Docker copies those files into the volume; mounting a non‑empty volume hides the existing files.

Usage

Create a volume: docker volume create Remove a specific volume: docker volume rm <volume_name> Remove all unused volumes: docker volume prune List volumes: docker volume ls Inspect a volume: docker volume inspect <volume_name> Mount to a container: -v or --volume (Docker 17.06+ prefers --mount)

Mount options include type (bind, volume, tmpfs), source, destination, read‑only flag, and driver‑specific options such as volume-opt.

When using docker service create , only --mount is supported; -v and --volume are not.

Scenarios

Sharing data between multiple running containers.

Decoupling container runtime configuration from the host’s directory layout.

Backup, restore, or migration of data between Docker hosts.

bind mount

A bind mount references a host file or directory by its absolute path. The host path does not need to exist beforehand; Docker will create it when using -v or --volume.

If a bind mount hides existing files in the container’s target directory, they become invisible; if the host path is missing, Docker reports an error with --mount but creates the directory with -v / --volume.

Usage

Mount to a container with -v or --volume; Docker 17.06+ recommends --mount.

Mount syntax for -v / --volume: source:target[:options] Mount syntax for --mount:

type=bind,source=<path>,target=<path>[,options]

Scenarios

In general, prefer volumes when possible.

Sharing configuration files (e.g., /etc/resolv.conf) between host and container.

Sharing source code or build artifacts.

Ensuring host directory structure matches container expectations.

bind propagation

By default bind mounts are rprivate ; propagation can be changed on Linux, but most users do not need to configure it.

Propagation determines whether a mount created inside one mount point is visible at another mount point.

Example:

docker run -d \
  -it \
  --name devtest \
  --mount type=bind,source="$(pwd)"/target,target=/app \
  --mount type=bind,source="$(pwd)"/target,target=/app2,readonly,bind-propagation=rslave \
  nginx:latest

Creating /app/foo/ also creates /app2/foo/ due to rslave propagation.

SELinux label

Use the z (shared) or Z (private) options to modify the SELinux label of the host path in the container. Misusing Z on system directories can render the host inoperable.

tmpfs mount

Supported only on Linux.

Tmpfs mounts keep data in host memory, are removed when the container stops, and cannot be shared between containers, making them ideal for temporary or sensitive data.

Usage

Mount with --tmpfs (or --mount on Docker 17.06+).

Options include type=tmpfs, destination, tmpfs-size, and tmpfs-mode.

volume drivers

Enable sharing data across machines.

Volume drivers abstract the underlying storage system, allowing you to switch between drivers (e.g., NFS, Amazon S3) without changing application code.

Usage

Create a volume with a driver:

docker volume create --driver vieux/sshfs \
  -o sshcmd=test@node2:/home/test \
  -o password=testpassword \
  sshvolume

Run a container using the driver:

docker run -d \
  --name sshfs-container \
  --volume-driver vieux/sshfs \
  --mount src=sshvolume,target=/app,volume-opt=sshcmd=test@node2:/home/test,volume-opt=password=testpassword \
  nginx:latest

Backup a container’s volume:

docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

Restore from backup:

docker run -v /dbdata --name dbstore2 ubuntu /bin/bash

docker run --rm --volumes-from dbstore2 -v $(pwd):/backup ubuntu bash -c "cd /dbdata && tar xvf /backup/backup.tar --strip 1"