Volumes, Named Volumes, Volume Drivers, Backup/Restore, Sharing, and Persistent Data Patterns: Configuration, Design Choices, and Tradeoffs

1. Named volume versus bind mount

Chapter 21 will explore bind mounts in depth. For persistent service state that should not depend on a workstation directory layout, named volumes are usually the clearer starting point.

2. Local versus plugin/remote volume drivers

The built-in local driver stores/provisions storage according to the daemon host and local driver options. Volume plugins can integrate external storage and can make data persist beyond one Docker host. That extra capability also adds a trust boundary, credentials, network dependency, performance profile, consistency model, and plugin lifecycle.

Never infer that a remote driver supports POSIX locking, multi-writer, snapshots, encryption, or failover merely because Docker successfully mounted it.

3. One writer versus shared access

Docker can attach the same named volume to multiple containers. That proves mountability, not correctness. Many embedded databases and stateful applications require a single writer or coordinated clustering protocol. Shared writable storage can corrupt data if the application and backend do not support concurrent access.

Use read-only consumers when possible. For multiple writers, document the application-level concurrency contract, storage protocol, locking/consistency behavior, failure recovery, and platform/driver prerequisites.

4. Crash-consistent versus application-consistent backup

Stopping a simple synthetic writer is enough for this course's file backup. A production PostgreSQL, MySQL, MongoDB, or other database needs its own supported backup/consistency method. Docker does not know the application's transaction boundaries.

5. Project-managed versus external Compose volume

A top-level Compose volume without external: true is normally created and labeled as part of the Compose project. docker compose down preserves such named volumes by default; adding --volumes opts into deleting them. An external volume is expected to exist outside the project's lifecycle and is never removed by down.

# Project-managed volume
services:
  app:
    image: busybox:1.36.1
    volumes:
      - app-data:/data
volumes:
  app-data: {}

# Externally managed volume
# volumes:
#   app-data:
#     external: true
#     name: shared-production-data

Use external ownership when creation/deletion belongs to another lifecycle, team, infrastructure system, or shared environment. Do not use it merely to avoid understanding Compose cleanup behavior.

6. Decision table

7. Worked scenario: analytics service with daily imported data

The service runs on one Docker host, imports a 2 GB dataset nightly, and must retain the previous day's recoverable state. A named local volume is reasonable if the host is the accepted failure domain. The operational contract should include a daily application-quiesced archive or host snapshot, checksum, retention policy, restore test, disk-space monitoring, and documented host-backup dependency.

If the requirement changes to “survive host loss with minutes of RPO,” the correct change is not a random volume plugin. Re-evaluate the application/data architecture, remote storage semantics, replication, and recovery objectives together.

8. Design checklist

• Who creates and deletes the volume?
• Which driver and exact driver options are required?
• Which containers may read and which may write?
• What numeric UID/GID and mode should persisted files have?
• What is the acceptable RPO and RTO?
• How is application consistency established before backup?
• Where is the backup stored relative to the host failure domain?
• How often is restore tested into a separate target?
• Which labels/metadata identify owner, environment, and retention?

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.