"a bind mount won't copy the container contents to the host automatically, unlike a named volume"

Question

Need clarity on a comment here:

The only 'problem' with a bind mount is that it won't copy the container contents to the host automatically, unlike a named volume. docs.docker.com/compose/compose-file/#volumes

Is this accurate? If yes, then:

1. how does one get the container's "new data" (e.g. a growing database) into the host when using a bind mount (to persist the data in case of a container restart)?
2. how did Docker persist data across container restarts before there were named volumes?

Answer 1

I think @BMitch having the accepted answer is correct, but I will just try to add in some details with the hope of being useful.

Is this accurate? If yes, then:

Given it is my claim being scrutinised - I totally defer to @BMitch here :)! However I would also add:

• https://github.com/docker/compose/issues/4581#issuecomment-389559090
  • Provides a layman explanation of how named volumes / host volumes behave
  • My explanation needs updated to reflect the notion of 'initialization'
• https://stackoverflow.com/a/40030535/3080207
  • This is how I would recommend setting up volumes in docker-compose at the moment, courtesy of @kaiser

how does one get the container's "new data" (e.g. a growing database) into the host when using a bind mount (to persist the data in case of a container restart)?

Both host volumes and named volumes can achieve this.

I think the point of contention is what you want to happen on the:

• first run of the container
• subsequent runs of the container and
• the location/accessibility of the volume on the host system.

Once a volume is attached to a container (be it a named volume or bind mount), whatever is stored to that volume should be persisted between restarts - that effectively comes for free. This assumes the same docker-compose config, and no manual removal of volumes.

Previously it was a bit limiting using a named volume, as you couldn't tail logs, or edit code directly from the host as easily as you could with a bind mount - but it seems that problem is resolved / has a work around now.

Bind mounts are able to persist data between restarts. I personally find that bind volumes do what I want 99% of the time, that being said, named volumes can now 'do it all' and I'd be using those moving forward.

There are differences between them though, and I'm sure they'll still bite people occasionally, requiring them to reach out to actual experts, instead of users like me :).