Docker Fundamentals · Module 07 of 12

Persistent storage: volumes, bind mounts and tmpfs

Choose the right storage mechanism and prove why container writable layers should not be treated as durable application data.

Learning objectives

By the end of this module, you should be able to:

Explain why container writable-layer data is coupled to that container instance.
Choose between named volumes, bind mounts and tmpfs for common use cases.
Create, inspect and safely remove Docker volumes.

Container writable layers are not your database strategy

A container has a writable layer while it exists, but deleting the container deletes that container-specific writable data. Durable application state should be intentionally stored outside the container lifecycle.

Volumes are Docker-managed persistent stores

Docker documentation describes volumes as the preferred mechanism for persistent data generated and used by containers. Docker manages their host location and lifecycle separately from the containers that mount them.

Bind mounts and tmpfs solve different problems

Bind mounts map a specific host path into a container and are useful when the host and container both need direct access to the same files, such as development source or configuration. A tmpfs mount is temporary and removed when the container stops; on Linux it uses kernel tmpfs, so data can still be written to swap if the host permits swapping. Use it for non-persistent runtime data, not as a guarantee that sensitive bytes can never reach storage.

Worked examples

See the idea in practice.

Named volume survives container replacement

docker volume create demo-data
docker run --rm -v demo-data:/data alpine:3.20 sh -c 'echo persistent > /data/value'
docker run --rm -v demo-data:/data alpine:3.20 cat /data/value

The first container is removed.
The second container sees the same volume data.

Bind mount a local file read-only

docker run --rm --mount type=bind,src="$PWD/config",dst=/config,readonly alpine:3.20 ls -l /config

The source is a host path.
readonly prevents container writes through that mount.

Hands-on lab

Lab — Prove persistence across container replacement

Goal: Store a value in a named volume, remove the container, and recover the value from a new container.

STEP 1

Create a volume

docker volume create gnu-course-data

STEP 2

Write data

docker run --name writer -v gnu-course-data:/data alpine:3.20 sh -c 'date -u > /data/created.txt; cat /data/created.txt'

STEP 3

Remove the writer container

docker rm writer

STEP 4

Read from a fresh container

docker run --rm -v gnu-course-data:/data alpine:3.20 cat /data/created.txt

STEP 5

Inspect and then clean up intentionally

docker volume inspect gnu-course-data
docker volume rm gnu-course-data

Verify

The value remains after the writer container is removed.
The volume has its own Engine-managed identity.

Expected outcome

A fresh container prints the timestamp written by the removed container.

If it fails

If volume removal says it is in use, locate containers still mounting it before forcing anything.
Be cautious with docker compose down -v or docker volume prune because persistent data can be permanently deleted.

Real-world connection

Databases, queues and stateful services commonly use named volumes when running on one Docker host; production orchestration may use external storage systems with stronger durability guarantees.

Avoid these traps

Common mistakes

Assuming deleting a container keeps data written only to its writable layer.
Using bind mounts without considering host path permissions and portability.
Running broad volume prune commands without understanding what data is still needed.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What happens to a named volume when a container using it is removed?

The volume can remain and be mounted by another container unless it is explicitly removed.

2When is a bind mount useful?

When a specific host file/directory must be directly visible inside the container, such as development source or configuration.

3When is tmpfs appropriate?

For temporary non-persistent runtime data. On Linux, tmpfs pages can still be written to swap depending on host configuration, so tmpfs is not an absolute no-disk guarantee.