Backup docker datapaths with or without running containers?

General
1

Hi all,

I want to create a backup from my docker datapaths on daily basis.

In my docker compose file I have multiple containers (e.g. a mysqldb):

Brief extract:

version: '3'

  mysqldb:
    image: mysql
    container_name: mysqldb
    restart: always
    ports:
      - 3306:3306
      - 33060:33060
    volumes:
      - /home/user/docker/mysql/etc/mysql/conf.d:/etc/mysql/conf.d
      - /home/user/docker/mysql/var/lib/mysql:/var/lib/mysql

I want to backup all data files from docker in /home/user/docker

Do I need to stop the containers for the backup itself avoid inconsistency in the data files (e.g. of the database)? What will happen to the read / write operations of mysql if I copy the datafiles without stopping the container? Are there any best practies? My approach would be to simply clone the datapath.

Thanks and kind regards
Itchy2

2

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 Docs 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 /var/lib/docker/volumes/<volume-name>).

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.