Checkpoint containers instead of stopping them
Checkpoint containers instead of stopping them When a Docker Compose backup copies its volumes, BackupMunk normally stops the stack for the copy and starts it again afterwards, so every process starts from scratch. With Docker checkpoint, BackupMunk instead freezes each running container to disk together with its memory, copies the volumes, and then resumes the containers from that checkpoint. Processes carry on where they were: no cold start, warm caches stay warm, and connections inside the stack are kept. You can also keep the checkpoints in the backup, so a restore can bring the containers back in their running state. Docker checkpoint uses Docker's experimental docker checkpoint feature, which is built on CRIU. Requirements A Linux host running Docker Engine. Docker Desktop and rootless Docker can't checkpoint containers. CRIU installed on the host — for example apt install criu on Debian, or dnf install criu on Fedora and RHEL. Docker running with experimental features turned on. BackupMunk can turn this on for you (see below). The agent running as root, as the packaged service does. [!WARNING] Docker 28 and later can't resume containers that use a bridge or other non-host network from a checkpoint (a Docker bug). On those versions BackupMunk only checkpoints containers that use the host network (network_mode: host); the others are stopped and started fresh, as in a normal backup. Docker 24 to 27 resume containers on any network. Turn on Docker checkpoint for a host Open Clients, choose the host, and find the Docker checkpoint card. It shows what the agent last reported: the Docker version, whether experimental features and live-restore are on, the CRIU version, and the Docker configuration file. Choose Check now to ask the agent again. Choose Turn on… and confirm. The agent then: saves a copy of the Docker configuration file (/etc/docker/daemon.json) next to it, adds "experimental": true and, if it isn't on yet, "live-restore": true, leaving your other settings as they are, checks the new configuration with dockerd --validate, reloads Docker so live-restore takes effect first, restarts Docker and waits for it to come back. With live-restore on, running containers keep running while Docker restarts. If Docker rejects the new configuration or doesn't come back, the agent puts the previous configuration back and restarts Docker again. The agent won't change the configuration while a backup or restore is running on the host, and it refuses if CRIU isn't installed. If the card says the agent can't change the configuration — for example because Docker isn't run by systemd on that host — add "experimental": true to the Docker configuration yourself and restart Docker. Turn off… removes "experimental" the same way, keeping a copy of the previous file. Use it in a backup In the backup's Options step, when containers are stopped for the copy, choose how they stop: Choice What happens Stop and start fresh The default. Works on every host. Checkpoint and resume Containers are checkpointed, the volumes are copied, and the containers resume from the checkpoint. The checkpoint is then deleted. Checkpoint, resume and keep As above, and each container's checkpoint is also stored in the backup. A checkpoint is about the size of the container's memory. It's added after the stack is running again, so it doesn't add downtime. Then choose what happens if a container can't be checkpointed: Stop it and start it fresh, and warn (recommended) — that container is backed up the normal way and the run shows a warning. Fail the backup — everything already checkpointed is resumed and the run fails, so a checkpoint problem is never hidden. The same applies when the host doesn't have Docker checkpoint turned on. Restore the running state When a backup holds checkpoints, the restore dialog offers Resume containers from their saved running state together with Start containers. The agent recreates the stack's containers and starts each one from its…
BackupMunk Enterprise documentation