Volumes, Named Volumes, Volume Drivers, Backup/Restore, Sharing, and Persistent Data Patterns: Concepts, Architecture, and Mental Model

1. The practical problem: container lifecycle is not data lifecycle

Earlier chapters deliberately treated containers as disposable objects. That model becomes dangerous if application state is left in the writable layer: deleting the container deletes that state. A volume moves the data lifecycle into a Docker-managed storage object that can remain after one container exits and be attached to a replacement container later.

This does not make the data magically safe. You still need an owner, a driver, permission rules, consistency assumptions, backup artifacts, restore tests, and an explicit retention/deletion decision. Persistence means the bytes can outlive a container; recoverability means you can prove a usable copy exists and restore it.

2. Mental model: object → storage → mount → writes → retained data

Start with the named volume object. Docker associates it with a driver and driver-specific options. When a container starts, the driver makes storage available and Docker mounts it at the declared container target. Application writes then land in that mounted storage rather than in the container writable layer. Stopping or replacing the container does not, by itself, delete the volume. Backup, restore, migration, or deletion are separate operations.

flowchart TD
  V[Volume object name + driver + options] --> S[Driver-provided storage local or remote]
  S --> M[Container mount target /data]
  M --> A[Application reads/writes]
  A --> R[Retained data independent of container]
  R --> B[Backup artifact checksum + timestamp]
  B --> X[Restore target new volume]
  X --> Q[Verification content + ownership + app semantics]
  R --> D[Intentional deletion after dependency check]
            

3. State you must identify before changing anything

4. Named versus anonymous volumes

A named volume has an explicit stable name such as da20-data. An anonymous volume is created without an explicit name, receives a generated identifier, and is harder to reconnect intentionally after container replacement. Both are separate volume objects. For state that must survive application updates, a named volume makes ownership and recovery intent far easier to express.

Container removal flags can clean anonymous volumes associated with a container, while named volumes survive ordinary container deletion. That asymmetry is one reason to avoid treating docker rm -v or Compose teardown as a casual storage-cleanup mechanism.

5. Mount behavior and the copy-up trap

Mounting a volume over a non-empty image directory obscures the underlying image files while the mount is active. When an empty volume is mounted at a path that already contains files in the container image, Docker normally copies that existing content into the volume. The volume-nocopy option disables that population behavior. Neither behavior should be discovered accidentally in production.

Read-only volume mounts are useful when one container should consume but not mutate shared data. The mount access mode is separate from the filesystem ownership/mode stored inside the volume.

6. Read-only inspection first

docker version
docker info
docker context show
docker compose version || true
docker buildx version || true

docker volume ls
docker ps -a --no-trunc

docker pull busybox:1.36.1
docker image inspect busybox:1.36.1 --format 'ID={{.Id}} RepoDigests={{json .RepoDigests}}'

# Example if a named volume already exists:
docker volume inspect da20-data 2>/dev/null || true

docker ps -a --filter volume=da20-data --no-trunc

docker ps -a --filter volume=da20-data -q | while read id; do
  [ -n "$id" ] && docker inspect "$id" --format 'Container={{.Name}} Mounts={{json .Mounts}}'
done

Do not enter Docker's internal storage directories and edit files there. The daemon and selected driver own that implementation. Use containers and documented volume APIs as the data-access boundary.

7. A backup is an artifact, not a belief

A useful backup record answers: which volume, which logical data version, when, under what consistency method, which archive checksum, and was restore actually tested? A tar file copied somewhere is not sufficient evidence if the source application was mutating files while the archive was created or if restored ownership makes the application unable to read them.

For ordinary files, a stopped/quiesced writer plus an archive and checksum can be enough. Databases often need their own snapshot, dump, checkpoint, replication, or backup API to achieve application consistency. Docker volume mechanics do not replace database-specific consistency guarantees.

8. DevOps connection: persistence is an operational contract

In a reproducible operating model, image digest, container configuration, volume identity, data version, ownership, backup checksum, restore target, and external storage assumptions are independently verifiable. This separation enables safe rollbacks: you can replace compute while retaining data, or restore data into a new volume without mutating the original evidence.

Knowledge check

Official references and version notes

• Docker Docs — Volumes — volume lifecycle, mount behavior, backup/restore examples, read-only mounts, volume-nocopy, subpaths, and removal.
• Docker CLI — docker volume — create, inspect, list, remove, prune, and update subcommands.
• Docker CLI — docker volume inspect — driver, labels, options, scope, creation timestamp, and mountpoint where the driver exposes one.
• Docker CLI — docker volume create — driver selection, driver options, labels, and cluster-volume options.
• Docker CLI — docker volume rm — exact volume removal and in-use protection.
• Compose Specification — top-level volumes — project-managed versus external volumes and driver/option declarations.
• Docker CLI — docker compose down — default retention, --volumes deletion semantics, and external-volume protection.
• Docker Docs — Volume plugins — driver boundaries and why remote/plugin semantics must be learned from the selected driver.
• Docker Engine 29 release notes — current Engine baseline.