Docker volume为有状态容器规划备份入口的实现方法

Docker volume 的关键不是“把目录挂到容器里”，而是把数据生命周期从容器生命周期中拆出来。推荐先创建一个有明确名称的命名 volume，再用 --mount 挂载到应用的数据目录；备份时启动一次性容器，把 volume 内容写入宿主机归档，恢复时换一个新 volume 解包。这样重建容器不会误删业务数据，也能把备份和恢复步骤做成固定入口。

官方地址：https://docs.docker.com/engine/storage/volumes/

第一步：先把 volume 和容器边界分开

假设应用把状态文件写入 /var/lib/app/data。先创建名为 app-data 的 volume，再启动容器。命名比匿名 volume 更适合运维，因为列表、备份和恢复时都能通过固定名称定位。

# 创建可被备份脚本稳定引用的命名 volume
docker volume create app-data

# 用显式参数挂载数据目录；--rm 只负责容器退出后的清理
docker run -d --name app-demo \
  --mount type=volume,src=app-data,dst=/var/lib/app/data \
  example/app:stable

# 检查 volume 的宿主机来源、容器目标路径和读写状态
docker inspect app-demo

检查结果重点看 Mounts：Type 应为 volume，Name 是 app-data，Destination 是应用实际写入的位置。不要把 Mountpoint 直接当作跨平台脚本接口，它是 Docker 主机上的管理路径。

第二步：把备份动作放进一次性容器

备份容器只需要同时看到两处目录：一个是待备份的 volume，另一个是宿主机的归档目录。下面的命令把归档写到当前目录的 backup/，并保留日期，避免每次执行覆盖同一个文件。

# 先准备宿主机归档目录；目录不属于 app-data volume
a='backup'; mkdir -p "$a"

# 一次性容器只读访问业务数据，并把 tar 写到宿主机目录
stamp=$(date +%Y%m%d-%H%M%S)
docker run --rm \
  --mount type=volume,src=app-data,dst=/source,readonly \
  --mount type=bind,src="$PWD/backup",dst=/backup \
  alpine:3.20 \
  tar czf "/backup/app-data-$stamp.tar.gz" -C /source .

# 用归档清单确认文件确实进入备份包
tar tzf "backup/app-data-$stamp.tar.gz" | head

备份期间应用仍可能写入文件，数据库、队列和索引类数据应先按应用自身的停写或快照方式处理；Docker 只负责挂载和打包，不会替你保证业务数据处于一致状态。若只读挂载用于备份，脚本不会因为误写备份容器而改变源数据。

第三步：用新 volume 演练恢复而不是覆盖原数据

恢复测试建议使用新的 app-data-restore，保留原 volume 作为回退。解包时用 -C /restore，避免把归档中的路径层级错误地套在目标目录上。

# 新建隔离的恢复目标，避免覆盖线上 volume
docker volume create app-data-restore

# 将归档解到恢复 volume，并把属主/权限检查留给应用验收
docker run --rm \
  --mount type=volume,src=app-data-restore,dst=/restore \
  --mount type=bind,src="$PWD/backup",dst=/backup,readonly \
  alpine:3.20 \
  sh -c 'tar xzf /backup/app-data-latest.tar.gz -C /restore && find /restore -maxdepth 2 -type f | sort | head'

# 以恢复 volume 启动隔离容器，确认应用能读取数据
docker run --rm --name app-restore-check \
  --mount type=volume,src=app-data-restore,dst=/var/lib/app/data \
  example/app:stable

验收至少包括文件数量、关键配置、应用启动日志和一次读写操作。确认无误后，再把正式服务切换到恢复 volume；不要因为归档文件存在就直接删除原 volume。

清理策略：删除容器不等于删除数据

docker container rm 只删除容器；命名 volume 仍然存在。确认备份可读、恢复演练完成后，才按项目保留策略删除过期归档和明确闲置的 volume。docker volume prune 影响范围较大，生产主机上应先列出候选项，避免把仍被恢复流程依赖的 volume 清掉。

常见问题

为什么不直接备份容器目录？

容器可写层属于容器本身，重建容器时不适合作为长期数据边界；volume 更容易单独管理、迁移和恢复。

空 volume 挂载后为什么出现了镜像里的文件？

Docker 默认会把目标目录已有内容复制到空 volume；如果不需要复制，可在 --mount 中使用 volume-nocopy，但要先确认应用需要的初始化文件不会因此缺失。

什么时候应该用 bind mount？

当宿主机程序必须直接访问明确目录时，bind mount 更合适；如果重点是 Docker 管理、迁移和容器间共享，优先使用 volume。