关键不是导出镜像本身，而是导出前需完成可验证、可加载、带上下文的备份准备：包括用docker commit固化运行态快照、同步命名卷与内核参数等宿主机状态，并在导出、传输、加载三阶段闭环验证。
物理机故障时快速恢复 Docker 镜像，关键不是“导出镜像”本身，而是导出前是否已做好可验证、可加载、带上下文的备份准备。单纯用 docker save 导出镜像只是第一步，若没同步状态、没验证可用性、没保留运行依赖，恢复时仍会卡在启动失败、配置缺失或数据不一致上。
必须导出的不只是镜像，还有运行态快照
故障发生前或刚停机时，如果容器还在（哪怕已停止未删除），优先执行：
-
docker commit -m "repro-20260813-db-hang" <container-id> app-recover:20260813</container-id>——固化实际运行中的文件系统：临时配置、调试工具、/tmp 日志、甚至被改过的 /proc/sys 参数 - 避免用
docker export：它丢弃 ENV、ENTRYPOINT、健康检查、重启策略等关键运行语义，恢复后容器行为可能完全不同 - 导出后立刻验证：
docker inspect app-recover:20260813 | jq '.[0].Config.Env, .[0].Config.Healthcheck'，确认环境变量和健康检查存在
单独打包外部依赖，否则镜像无法真正运行
Docker 镜像本身不含卷数据、设备权限、内核参数等宿主机级状态，这些必须一并采集：
-
命名卷数据：用
docker volume inspect vol-name查路径，再tar -cf vol-data-20260813.tar /var/lib/docker/volumes/vol-name/_data -
设备节点权限：如
/dev/ttyS0或/dev/video0，记录 UID/GID 和 mode：stat -c "%U:%G %a" /dev/ttyS0，目标机需重建相同权限 -
关键内核参数：若故障与调度、内存压力相关，保存：
cat /proc/sys/kernel/sched_rt_runtime_us /proc/sys/vm/swappiness > kernel-state-20260813.txt
导出+传输+加载，三步要闭环验证
导出不是终点，每一步都需确认有效性：
-
导出阶段：用
docker save -o app-recover-20260813.tar app-recover:20260813，生成 tar 后立即校验：tar -tf app-recover-20260813.tar | head -n5看是否有 manifest.json 和 layer 文件夹 -
传输阶段：优先用
rsync -avz --checksum，启用校验和比对，防止网络传输损坏；大镜像可加--partial支持断点续传 -
加载阶段：在目标物理机执行
docker load -i app-recover-20260813.tar后，必须跑一次轻量验证：docker run --rm app-recover:20260813 sh -c "echo ready && exit 0"
恢复时别只启动镜像，要还原完整运行上下文
镜像加载成功 ≠ 服务能跑。目标物理机还需：
- 按备份的
kernel-state-20260813.txt设置 sysctl 参数（如需） - 解压
vol-data-20260813.tar到对应卷路径，并确保目录属主与原环境一致（如 mysql 容器需chown -R 999:999 _data） - 用
docker run启动时，复用原容器的关键参数：--restart=unless-stopped、--memory=2g、--device=/dev/ttyS0、--cap-add=SYS_ADMIN等 - 若用 docker-compose，把镜像名、卷挂载、设备映射、sysctls 全部写进
docker-compose.recover.yml，一键启动
