podman-con...-checkpoint(1)
πΈ NAME πΈ
okay so bestie, welcome to the podman-container-checkpoint(1) page from the General Commands Manual π β yes, we folded the manual name right in here. This command is podman-container-checkpoint β it checkpoints one or more running containers. slay.
β¨ SYNOPSIS β¨
podman container checkpoint [options] container [container ...]
π¦ DESCRIPTION π¦
podman container checkpoint checkpoints all the processes in one or more containers. A container can be restored from a checkpoint with podman-container-restore. The container IDs or names are used as input. iykyk.
IMPORTANT: if the container is using systemd as entrypoint, checkpointing the container might not be possible π β not me finding out the hard way.
π OPTIONS π
--all,-aβ Checkpoint all running containers. The default isfalse. IMPORTANT: this OPTION does not need a container name or ID as input argument.--compress,-c=zstd | none | gzipβ Specify the compression algorithm used for the checkpoint archive created with the--export,-eOPTION. Possible algorithms arezstd,noneandgzip. One possible reason to usenoneis to enable faster creation of checkpoint archives. Not compressing the checkpoint archive can result in faster checkpoint archive creation. The default iszstd.--create-image=imageβ Create a checkpoint image from a running container. This is a standard OCI image created in the local image store. It consists of a single layer that contains all of the checkpoint files. The content of this image layer is in the same format as a checkpoint created with--export. A checkpoint image can be pushed to a standard container registry and pulled on a different system to enable container migration. In addition, the image can be exported withpodman image saveand inspected withpodman inspect. Inspecting a checkpoint image displays additional information, stored as annotations, about the host environment used to do the checkpoint:io.podman.annotations.checkpoint.name: Human-readable name of the original container.io.podman.annotations.checkpoint.rawImageName: Unprocessed name of the image used to create the original container (as specified by the user).io.podman.annotations.checkpoint.rootfsImageID: ID of the image used to create the original container.io.podman.annotations.checkpoint.rootfsImageName: Image name used to create the original container.io.podman.annotations.checkpoint.podman.version: Version of Podman used to create the checkpoint.io.podman.annotations.checkpoint.criu.version: Version of CRIU used to create the checkpoint.io.podman.annotations.checkpoint.runtime.name: Container runtime (e.g.,runc,crun) used to create the checkpoint.io.podman.annotations.checkpoint.runtime.version: Version of the container runtime used to create the checkpoint.io.podman.annotations.checkpoint.conmon.version: Version of conmon used with the original container.io.podman.annotations.checkpoint.host.arch: CPU architecture of the host on which the checkpoint was created.io.podman.annotations.checkpoint.host.kernel: Version of Linux kernel of the host where the checkpoint was created.io.podman.annotations.checkpoint.cgroups.version: cgroup version used by the host where the checkpoint was created.io.podman.annotations.checkpoint.distribution.version: Version of host distribution on which the checkpoint was created.io.podman.annotations.checkpoint.distribution.name: Name of host distribution on which the checkpoint was created.
--export,-e=archiveβ Export the checkpoint to an archive. The archive type is specified with--compress. The exported checkpoint can be used to import the container on another system and thus enabling container live migration. This checkpoint archive also includes all changes to the container's root file-system, if not explicitly disabled using--ignore-rootfs.--file-locksβ Checkpoint a container with file locks. If an application running in the container is using file locks, this OPTION is required during checkpoint and restore. Otherwise checkpointing containers with file locks is expected to fail. If file locks are not used, this option is ignored. The default isfalse.--ignore-rootfsβ If a checkpoint is exported to an archive it is possible with the help of--ignore-rootfsto explicitly disable including changes to the root file-system into the checkpoint archive file. The default isfalse. IMPORTANT: this OPTION only works in combination with--export,-e.--ignore-volumesβ This OPTION must be used in combination with the--export,-eOPTION. When this OPTION is specified, the content of volumes associated with the container is not included into the checkpoint archive. The default isfalse.--keep,-kβ Keep all temporary log and statistics files created by CRIU during checkpointing. These files are not deleted if checkpointing fails for further debugging. If checkpointing succeeds these files are theoretically not needed, but if these files are needed Podman can keep the files for further analysis. The default isfalse.--latest,-lβ Instead of providing the container ID or name, use the last created container. The default isfalse. IMPORTANT: this OPTION is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines. This OPTION does not need a container name or ID as input argument.--leave-running,-Rβ Leave the container running after checkpointing instead of stopping it. The default isfalse.
To keep the checkpoint consistent, Podman freezes the container's cgroup before dumping its memory and only thaws it again after the root file-system changes and named volumes have been captured. This means the container is paused for the duration of the checkpoint, but its memory image and file system are guaranteed to reflect the same point in time. Containers started with --cgroups=disabled cannot be frozen and therefore do not get this guarantee. If freezing the container fails, Podman continues with checkpointing and warns that this consistency guarantee could not be provided.
--pre-checkpoint,-Pβ Dump the container's memory information only, leaving the container running. Later operations supersedes prior dumps. The default isfalse.
The functionality to only checkpoint the memory of the container and in a second checkpoint only write out the memory pages which have changed since the first checkpoint relies on the Linux kernel's soft-dirty bit, which is not available on all systems as it depends on the system architecture and the configuration of the Linux kernel. Podman verifies if the current system supports this functionality and return an error if the current system does not support it.
--print-statsβ Print out statistics about checkpointing the container(s). The output is rendered in a JSON array and contains information about how much time different checkpoint operations required. Many of the checkpoint statistics are created by CRIU and just passed through to Podman. The following information is provided in the JSON array:podman_checkpoint_duration: Overall time (in microseconds) needed to create all checkpoints.runtime_checkpoint_duration: Time (in microseconds) the container runtime needed to create the checkpoint.freezing_time: Time (in microseconds) CRIU needed to pause (freeze) all processes in the container (measured by CRIU).frozen_time: Time (in microseconds) all processes in the container were paused (measured by CRIU).memdump_time: Time (in microseconds) needed to extract all required memory pages from all container processes (measured by CRIU).memwrite_time: Time (in microseconds) needed to write all required memory pages to the corresponding checkpoint image files (measured by CRIU).pages_scanned: Number of memory pages scanned to determine if they need to be checkpointed (measured by CRIU).pages_written: Number of memory pages actually written to the checkpoint image files (measured by CRIU).
The default is false.
--tcp-establishedβ Checkpoint a container with established TCP connections. If the checkpoint image contains established TCP connections, this OPTION is required during restore. Defaults to not checkpointing containers with established TCP connections. The default isfalse.--with-previousβ Check out the container with previous criu image files in pre-dump. It only works onrunc 1.0-rc3or higher. The default isfalse. IMPORTANT: this OPTION is not available with--pre-checkpoint.
This option requires that the option --pre-checkpoint has been used before on the same container. Without an existing pre-checkpoint, this option fails.
Also see --pre-checkpoint for additional information about --pre-checkpoint availability on different systems.
π₯ EXAMPLES π₯
Make a checkpoint for the container "mywebserver". periodt.
# podman container checkpoint mywebserver
Create a checkpoint image for the container "mywebserver". it's giving main character energy.
# podman container checkpoint --create-image mywebserver-checkpoint-1 mywebserver
Dumps the container's memory information of the latest container into an archive.
# podman container checkpoint -P -e pre-checkpoint.tar.zst -l
Keep the container's memory information from an older dump and add the new container's memory information. obsessed.
# podman container checkpoint --with-previous -e checkpoint.tar.zst -l
Dump the container's memory information of the latest container into an archive with the specified compress method.
# podman container checkpoint -l --compress=none --export=dump.tar
# podman container checkpoint -l --compress=gzip --export=dump.tar.gz
π SEE ALSO π
okay bestie go read these too: podman(1), podman-container-restore(1), criu(8).
π HISTORY π
September 2018, Originally compiled by Adrian Reber areber@redhat.com β¨mailto:areber@redhat.comβ©
and that's a wrap π
this page is podman-con...-checkpoint(1), dated September 2018 β mwah π«Ά slay forever.
π¦ where this page comes from
- arch rolling: podman 6.1.4-1 Β· Apache-2.0
- centos-stream 10: podman 7:6.1.0-2.el10 Β· Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND MIT AND MPL-2.0
- nixpkgs unstable: podman 6.1.4
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms