Whatever is needed when not using Docker is certainly needed when using Docker, as Docker does not provide any additional magic for backups. So, if some database you’re using needs to be shut down before doing a backup, then you’ll need to stop the container.
But even if the database/application/… allows for hot backups (like creating consistent snapshots, or backing up transaction log files), then still I’d assume your mileage with bind mounts (like you use above) may vary: due to latency and throughput limits, especially on non-Linux Docker installations, you may not know when such process has finished writing the files. That’s just a hunch though; if such process creates a clear set of files to copy, then it may work just fine. (Aside: on the one Windows server I used for Docker we actually disabled the generic Windows backup, as it would somehow make Docker become unresponsive every night.)
For volumes, Manage data in Docker | Docker Documentation also mentions stopping the containers first:
When you need to back up, restore, or migrate data from one Docker host to another, volumes are a better choice. You can stop containers using the volume, then back up the volume’s directory (such as
It also mentions the limitations of bind mounts on non-Linux hosts:
When your application requires fully native file system behavior on Docker Desktop. For example, a database engine requires precise control over disk flushing to guarantee transaction durability. Volumes are stored in the Linux VM and can make these guarantees, whereas bind mounts are remoted to macOS or Windows, where the file systems behave slightly differently.