Docker checkpoint：容器快照与恢复

理解 Docker checkpoint：容器快照到底保存了什么

Docker checkpoint 并非传统的镜像层打包，而是基于 CRIU（Checkpoint/Restore In Userspace）技术对容器运行时状态的完整冻结。与 docker commit 仅保存文件系统差异不同，checkpoint 会捕获容器内所有进程的内存页、CPU 寄存器状态、打开的文件描述符、网络套接字以及进程树拓扑，并将其序列化到磁盘。这种机制使得容器能够在任意时间点暂停并保存现场，后续可精确恢复到该瞬间的执行上下文。它主要适用于长周期计算任务中断续跑、容器热迁移调试以及复杂有状态服务的故障快照分析。使用前提包括：宿主机内核需开启 CONFIG_CHECKPOINT_RESTORE 选项，Docker 版本需支持实验性特性或已默认集成 CRIU 插件，且容器内运行的进程需兼容 CRIU 的内存与文件描述符转储规则。

创建 checkpoint：从运行中的容器生成快照

创建 checkpoint 前需确保环境就绪：在 Ubuntu 系统中可通过 sudo apt install criu 安装依赖，CentOS/RHEL 则使用 sudo yum install criu。启动目标容器后，执行 docker ps 确认其处于 Up 状态且无异常退出记录。随后运行 docker checkpoint create <容器名或ID> <快照名称> 即可触发快照流程。若希望容器在生成快照期间继续提供服务，可追加 --leave-running 参数；如需自定义存储路径，可使用 --checkpoint-dir 指定目录。命令执行成功后，终端会返回 Checkpoint created successfully 提示。此时可通过 docker checkpoint ls <容器名> 查看已生成的快照列表，或直接检查 /var/lib/docker/containers/<容器ID>/checkpoints/ 目录下是否生成了对应的 checkpoint-<名称> 文件夹，以此确认快照数据已完整落盘。

恢复 checkpoint：让容器回到快照时刻

恢复操作通过 docker start --checkpoint <快照名称> <容器名> 触发。执行后，Docker 会调用 CRIU 将之前序列化的内存与进程状态重新注入新启动的容器实例中，容器内的主进程及其子进程将精确回到快照时刻的指令指针与变量状态。恢复完成后，可通过多种方式验证：首先使用 docker exec <容器名> ps aux 确认进程树与快照前一致；其次检查应用日志或业务状态文件（例如若容器运行计数器服务，可观察数值是否从断点继续递增而非重置）；最后通过 docker inspect 查看容器状态是否已转为 Running。需注意，TCP 连接在恢复后通常处于断开状态，应用层需具备重连机制，但内存中的会话数据与未持久化的中间计算结果将得以保留。

验证与避坑：哪些场景下 checkpoint 可能失效

验证恢复是否成功需结合业务逻辑与系统状态交叉比对，但 checkpoint 并非万能，存在明确的兼容性边界。首先，CRIU 对内核版本有硬性要求（通常需 4.0 以上），低版本内核会直接拒绝转储。其次，容器运行时若未正确配置或 runc 版本过旧，可能导致状态注入失败。网络层面是常见失效点：未使用 --tcp-established 参数时，已建立的 TCP 连接在恢复后会被强制关闭，依赖长连接的服务将报错。此外，外部挂载卷、宿主机设备映射及特权模式下的硬件访问均不会被快照捕获，若应用强依赖这些外部状态，恢复后必然异常。务必明确：checkpoint 仅保存运行时上下文，绝非数据备份方案，生产环境中应配合持久化存储与常规备份策略使用，并在隔离环境充分测试后再应用于关键业务。