Storage and Volumes
Where bytes live
An image is read-only layers; a container adds a thin writable layer managed by the storage driver (overlay2). That layer is deleted with the container, so anything you must keep belongs on a volume or bind mount.
Volumes are managed by Docker under the data root (/var/lib/docker/volumes by default), are the recommended mechanism, and support volume drivers for NFS or cloud storage. Bind mounts map an arbitrary host path. tmpfs lives in memory and vanishes on stop.
-v versus --mount
-v is terse and forgiving: -v mydata:/data creates the volume if absent, and -v /host/path:/ctr creates the host directory if it is missing - often a silent bug. --mount type=bind,source=/host/path,target=/ctr fails loudly when the source does not exist, which is safer in scripts and CI.
Lifecycle: docker volume ls, inspect, create, prune. docker rm -v removes anonymous volumes attached to that container; named volumes survive. docker system prune --volumes is destructive and removes unused volumes. docker cp moves files in and out of a container without a mount.
Traps
Mounting over a non-empty container directory hides whatever the image put there - a classic "my config disappeared" symptom. Two containers can share one named volume, which is the basis of the --volumes-from pattern. The storage driver and the volume driver are different things; a question may try to conflate them.
Worked example
Back up a volume by mounting it beside a host directory into a throwaway container:
docker run --rm -v myvol:/data -v "$PWD":/backup alpine tar czf /backup/data.tar.gz -C /data .