Where a container's writes actually go, and why they vanish when the container does. The thin writable layer and copy-on-write, the three ways to keep data outside it — named volumes, bind mounts, tmpfs — the volume lifecycle and the anonymous-volume sprawl that fills disks, bind mounts in development and the directory-clobbering footgun, volume drivers that reach past the local disk, and the backup pattern that turns a volume into something you can actually restore.
6 topics
A container is disposable, and so is everything it writes to its own filesystem. That single fact is the reason this chapter exists: Driftwood's db container loses every bookmark the moment it's replaced, because Postgres wrote into the container's writable layer instead of somewhere durable. The fix is a named volume, and the chapter builds out from there into the full catalog of how data leaves the disposable layer.
The shape of the chapter follows the shape of the problem. First, where writes go and why copy-on-write makes them both slow and ephemeral. Then the three places to put data instead — a Docker-managed named volume, a host path bind-mounted in, or a RAM-only tmpfs — and how to tell which one a flag actually selects. Then the named-volume lifecycle and the anonymous volumes that pile up unnoticed, bind mounts as the development workflow and their sharpest footgun, volume drivers for storage that isn't this host's local disk, and finally the backup pattern that protects data Docker itself will not back up for you.