Don't Panic: Container Storage

A container filesystem looks like one ordinary tree of files, which is a useful illusion right up to the point where something important vanishes. The tree begins with image layers, gains a private writable layer when the container starts, and can have selected paths replaced by mounts. One view, several lifecycles. This is less mystical than it sounds, although the filesystem does make a decent job of wearing a false moustache.

The writable layer is the first trap. It is where new files and changed image files appear, and it belongs to one container. Remove that container and the layer goes with it. That is excellent for rebuildable cache and temporary extraction. It is a poor retirement plan for database files, uploads, or the only copy of anything that would make tomorrow unnecessarily exciting.

A volume gives a chosen path a life separate from the container. Replace the container, attach the same volume, and the data can remain. A bind mount instead shows the container an exact path from the daemon host. Use that when the host and container genuinely need the same files, not because a host directory feels more familiar. A tmpfs mount keeps temporary files in memory while the container runs, then removes them when it stops. Each choice answers a different question about what should survive.

The surprise is that persistence is only one question. A volume can outlive a container and still be full, inaccessible to the container user, absent on another host, or unrecoverable after the wrong deletion. A shared mount also does not make simultaneous writes safe. Storage has a talent for remaining technically present while being operationally useless.

Start with the Course tab when you need the full model of layers, mounts, and failure behavior. The Cheatsheet is the fast map for destinations, lifecycle rules, and operational tests. Use the Practice tab to replace a container on purpose and observe what remains. Then follow the Reference tab into orchestrator storage, where scheduling, attachment, topology, and recovery add several more moving parts, because apparently one filesystem was not enough.