← Docker: run and diagnose containers
04 / 6 · 40 MIN

Data and mounts

Choose persistence and interpret mounts without losing data provenance.

Concept and mechanism

A container writable layer follows that instance; removing it may remove data never stored elsewhere. A named volume separates the data lifecycle from the container. This is neither backup nor cross-host recovery. Define ownership, retention, consistency, and restore testing for the application. A bind mount connects a specific path on the daemon host to the container and creates a dependency on that structure. With a remote daemon, the path is not resolved on the laptop running the CLI. Confirm actual source and target before interpreting missing files or creating directories merely to make startup succeed.

Guided application

In a fictional case, the image contains /app/config but an empty bind mount is placed on that path. The mount obscures earlier content; this does not establish that the build deleted it. Compare configuration and image in an isolated diagnostic instance before correcting the source. Empty volumes may receive initial image content by default, unlike this bind mount. When the application only reads configuration, a read-only mount can limit host changes. Do not solve permissions by granting global write access: relate the process user, identifiers, and necessary permissions. Copying files from a running database also requires a consistency method, not merely a persistent destination.

IN PRACTICE

A new container with the correct volume retains data; a new writable layer does not recover a removed earlier layer.

Common pitfalls

Persistence as backup; client path as daemon path; mount as file deletion.

Related topics: Processes and images · Build and distribution · Networking and access

Take this idea with you

Document where data lives and how it returns to a consistent state.

Create account

Reference: Volume lifecycle and mount behavior · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped