镜像、容器、数据卷需分别备份：镜像用docker save导出或推送私有仓库；容器备份重在配置和可写层（commit为镜像）；数据卷须单独tar或rsync备份；恢复时按镜像→数据→配置顺序操作并验证版本兼容性。
镜像和容器是 docker 的两个基础但易混淆的概念，它们在备份与恢复中扮演不同角色。镜像是静态只读模板，容器是它的运行实例；备份不能只盯着“容器”本身，而要分清：该备份镜像、还是容器状态、还是数据卷——三者策略完全不同。
镜像备份：导出为 tar 文件或推送到仓库
镜像本身不随容器运行而变化，适合用 docker save 导出为归档文件：
-
docker save -o app-v2.1.tar myapp:v2.1—— 保存单个镜像 -
docker save $(docker images -q) | gzip > full-images-$(date +%F).tar.gz—— 批量压缩所有本地镜像 - 企业级场景建议推送至私有 registry：
docker tag myapp:v2.1 reg.example.com/prod/myapp:v2.1 && docker push reg.example.com/prod/myapp:v2.1
注意：save 保留完整层结构和元数据，加载时用 docker load -i xxx.tar 即可还原，无需网络依赖。
容器备份：本质是“保存运行时状态+数据”
容器本身不可直接备份，因为它的生命周期短暂、可写层随删除而消失。真正需要备份的是：
-
配置信息：启动命令、端口映射、环境变量等，应来自
docker-compose.yml或脚本，而非靠记忆重建 -
可写层内容：若必须保留临时修改（如调试中生成的配置），可用
docker commit提交为新镜像：docker commit -m "backup before upgrade" container-id myapp:backup-20260915 -
运行状态快照：Docker 原生不支持内存/进程状态快照，需暂停后手动备份
/var/lib/docker/containers/<id>目录（仅限紧急场景，需停 Docker 服务才能安全恢复）
数据卷备份：容器数据持久化的关键环节
绝大多数业务数据（MySQL 数据库、上传文件、日志归档）都存在命名卷（named volume）或绑定挂载（bind mount）中，这才是备份重点：
- 命名卷备份示例：
docker run --rm -v mydb:/source -v $(pwd):/backup alpine tar -czf /backup/mydb-volume-$(date +%F).tar.gz -C /source . - 恢复时先创建同名卷：
docker volume create mydb，再用类似命令解压回填 - 绑定挂载更简单：直接对宿主机目录执行
rsync或tar备份，路径清晰、权限可控
切记：不要把数据库文件放在容器可写层，否则容器一删，数据全无。
恢复全流程：按对象类型分别操作
恢复不是“一键还原”，而是组合动作：
- 先加载镜像：
docker load -i app-v2.1.tar - 再准备数据卷：从备份 tar 解压到对应 volume 或宿主机路径
- 最后用原始配置启动容器：
docker-compose up -d或docker run ... - 验证：检查容器日志、连通性、业务接口是否正常返回
一次有效的恢复，必须确保镜像、配置、数据三者版本匹配——比如用 v2.1 镜像加载 v2.0 的数据库备份，可能因结构变更导致启动失败。
