Docker 数据卷备份与恢复：从挂载确认到校验

Docker 数据卷的备份重点不在直接寻找宿主机目录，而在于确认“哪个卷、挂到哪个容器路径、何时停止写入”。比较稳妥的做法是先用 docker volume inspect 和容器挂载信息确认边界，再用一次性容器把卷内容打成 tar，恢复到新卷后用文件清单和 sha256 做验收。

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

第一步：先确认卷和真实挂载关系

示例使用命名卷 app-data。先列出卷，再查看详细配置；这里关注的是 Docker 返回的字段，而不是凭经验猜测宿主机目录。

# 列出卷，确认目标名称没有写错
docker volume ls

# 查看驱动、Mountpoint、Name 等卷级信息
docker volume inspect app-data

# 找出当前使用这个卷的容器
docker ps --filter volume=app-data --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

如果卷的 Driver 不是预期的 local，要先确认对应驱动是否支持这种归档方式。对容器还要继续看 Mounts，确认卷在容器内的目标目录，例如 /data，以及 RW 是否为 true。以下是这一核对动作的原创界面说明图，不是实际 Docker 截图。

第二步：先处理持续写入，再开始归档

数据库、上传服务或日志组件仍在写入时直接打包，可能得到内部时间点不一致的文件。生产环境应先暂停应用写入，或使用应用自身的一致性快照；本文只演示 Docker 卷层面的归档动作。确认写入边界后，准备一个存放备份文件的当前目录。

# 记录本次备份使用的文件名，避免误覆盖旧归档
backup_file="app-data-20261007.tar"

# 确认当前目录就是允许写入备份文件的位置
pwd
ls -ld .

不要为了省事直接修改 docker volume inspect 输出里的宿主机 Mountpoint。使用临时容器可以让备份逻辑保持在 Docker 的挂载边界内，也更容易迁移到另一台 Docker 主机。

第三步：用临时容器生成 tar 备份

下面的命令把命名卷挂到临时容器的 /source，把宿主机当前目录挂到容器的 /backup，然后只在临时容器里执行归档。--rm 会在命令结束后清理这个一次性容器。

# 将 app-data 内容归档到宿主机当前目录，不暴露 Docker 内部存储路径
docker run --rm \
  --mount source=app-data,target=/source,readonly \
  --mount type=bind,source="$PWD",target=/backup \
  ubuntu:24.04 \
  tar -C /source -cvf /backup/app-data-20261007.tar .

# 记录归档大小与摘要，后续恢复后用于抽样核对
ls -lh app-data-20261007.tar
sha256sum app-data-20261007.tar

这里把源卷设为只读，避免归档过程意外写入数据。命令正常结束后，当前目录应出现 tar 文件；若容器镜像不可用、权限不足或备份目录不可写，应先修复执行环境，不要把空文件当成成功备份。

第四步：创建新卷并恢复归档内容

恢复时先创建一个不同名称的新卷，保留原卷作为回退点。归档命令把当前目录挂到 /backup，把新卷挂到 /restore；--strip-components=1 用来去掉归档中可能存在的顶层目录，避免恢复后变成 /restore/source/...。

# 创建独立恢复卷，原卷暂时不要删除
docker volume create app-data-restore

# 解压到新卷；先进入目标目录再展开归档内容
docker run --rm \
  --mount source=app-data-restore,target=/restore \
  --mount type=bind,source="$PWD",target=/backup,readonly \
  ubuntu:24.04 \
  bash -c 'cd /restore && tar -xvf /backup/app-data-20261007.tar --strip-components=1'

如果归档原本是用 tar -C /source ... . 生成的，里面没有多余的 source 目录，此时可以去掉 --strip-components=1；关键是先用 tar -tf 查看归档路径层级，再选择解压参数。

# 先查看归档的前几条路径，确认是否存在顶层目录
tar -tf app-data-20261007.tar | sed -n '1,12p'

第五步：用清单和哈希完成最终校验

恢复卷能够创建，只说明解压动作完成；是否能被应用使用，还要检查文件结构。可以用两个临时容器分别生成相对路径清单，再对数据库文件、配置文件或业务关键文件抽样计算哈希。不要只比较 tar 文件的哈希，因为恢复后的文件系统元数据和归档格式可能不同。

# 从源卷和恢复卷导出排序后的相对文件清单
docker run --rm --mount source=app-data,target=/data,readonly ubuntu:24.04 \
  bash -c 'cd /data && find . -type f -print | sort' > source-files.txt
docker run --rm --mount source=app-data-restore,target=/data,readonly ubuntu:24.04 \
  bash -c 'cd /data && find . -type f -print | sort' > restore-files.txt

# 先比较数量和清单，再对指定关键文件做内容摘要
wc -l source-files.txt restore-files.txt
diff -u source-files.txt restore-files.txt
docker run --rm --mount source=app-data,target=/data,readonly ubuntu:24.04 \
  sha256sum /data/config/app.yaml
docker run --rm --mount source=app-data-restore,target=/data,readonly ubuntu:24.04 \
  sha256sum /data/config/app.yaml

当清单一致、关键文件摘要一致，并且测试容器能以预期路径读取恢复卷时，才适合安排服务切换。以下说明图展示恢复卷、归档文件和校验结果之间的关系，不是运行截图。

几个容易忽略的边界

常见问题

为什么不直接复制 Mountpoint 目录？

Mountpoint 是 Docker 返回的管理信息，直接依赖宿主机内部路径会把驱动、权限和平台差异带进备份流程。临时容器方式更容易复用，也不会把内部目录结构写死。

恢复时可以覆盖原卷吗？

不建议第一次就覆盖。先恢复到新卷并完成清单、哈希和应用读取测试，确认后再安排切换；原卷至少保留到回退窗口结束。

tar 文件哈希一致是否代表恢复成功？

不代表。它只能说明归档文件本身没有变化，仍需比较恢复后的文件清单、关键文件内容和容器内实际挂载路径。

这套流程的验收顺序是“卷与挂载确认—停止写入—归档—新卷恢复—清单与哈希复核”。把每个状态记录下来，备份才从一个文件变成可回退、可解释的恢复方案。