Docker 数据持久化详解：Volume 与 Bind Mount 的区别

前言

使用 Docker 部署应用时，经常需要保存数据库文件、上传的图片或程序配置。有时容器删除后数据还在，有时重新创建容器却发现原来的文件不见了。

这主要涉及 Docker 的数据持久化机制。

Docker 最常用的持久化方式有两种：Volume（数据卷）和 Bind Mount（绑定挂载）。两者都能将数据保存在容器可写层之外，但管理方式和适用场景有所不同。

一、为什么容器需要数据持久化？

Docker 容器默认有自己的可写层。如果应用直接把数据写在这个可写层中，停止并重新启动同一个容器通常不会丢失数据，但删除容器后，这些数据一般也会随之消失。

例如，在容器内部创建：

echo "hello" > /data/test.txt

如果 /data 没有挂载外部存储，那么文件就保存在容器的可写层中。

当容器被删除并重新创建时，新的容器通常不会继承旧容器可写层里的文件。

因此，数据库、用户上传文件和需要长期保留的配置，不应该只依赖容器的可写层。

二、Volume：由 Docker 管理的数据卷

Volume 是 Docker 原生提供的数据持久化方式。

可以先创建一个命名数据卷：

docker volume create app-data

查看数据卷列表：

docker volume ls

然后启动容器，将数据卷挂载到 /data：

docker run -d \
  --name demo \
  --mount type=volume,source=app-data,target=/data \
  alpine:3.20 sleep 3600

此时容器对 /data 的读写操作会作用于这个数据卷。

写入一个测试文件：

docker exec demo sh -c 'echo hello > /data/test.txt'

删除容器：

docker rm -f demo

然后使用同一个数据卷创建新容器：

docker run --rm \
  --mount type=volume,source=app-data,target=/data \
  alpine:3.20 cat /data/test.txt

正常情况下仍然可以看到：

hello

这说明数据并不依赖原来那个容器继续存在。

Volume 的实际存储位置由 Docker 管理。可以通过下面的命令查看数据卷信息：

docker volume inspect app-data

一般不建议直接进入 Docker 内部存储目录修改数据，日常管理应优先通过 Docker 挂载或官方支持的方式进行。

三、Bind Mount：直接挂载宿主机目录

Bind Mount 的思路更加直接：把宿主机上的某个文件或目录映射进容器。

例如，先在宿主机创建目录：

mkdir -p /opt/myapp/data

然后启动容器：

docker run -d \
  --name demo-bind \
  --mount type=bind,source=/opt/myapp/data,target=/data \
  alpine:3.20 sleep 3600

此时，容器里的 /data 对应宿主机的 /opt/myapp/data。

在容器中写入文件：

docker exec demo-bind sh -c 'echo hello > /data/test.txt'

回到宿主机查看：

cat /opt/myapp/data/test.txt

就能看到相同的内容。

这种方式很适合需要直接在宿主机查看或编辑的文件，例如网站静态资源、应用配置和开发环境中的源代码。

不过，Bind Mount 依赖宿主机的实际目录路径。迁移到另一台服务器时，需要确保对应目录和数据已经准备好。

四、两种挂载方式怎么选？

可以简单对比一下：

对于 MySQL、Redis 等需要长期保存数据的服务，可以考虑使用命名 Volume。

对于 Nginx 配置、网站静态文件或者需要经常手动修改的目录，Bind Mount 通常更加方便。

当然，这不是绝对规则。数据库同样可以使用 Bind Mount，关键是正确处理文件权限、备份和迁移。

五、在 Docker Compose 中使用

实际部署时，很多人会使用 Docker Compose 管理容器。

例如下面这个简单配置：

services:
  demo:
    image: alpine:3.20
    command: ["sleep", "3600"]
    volumes:
      - app-data:/data
      - ./config:/app/config:ro

volumes:
  app-data:

这里使用了两种不同的挂载方式：

app-data:/data 表示使用命名 Volume，将其挂载到容器的 /data 目录。

./config:/app/config:ro 表示将 Compose 项目目录下的 config 文件夹绑定挂载到容器中，:ro 代表只读，避免容器通过该挂载修改配置文件。

启动前可以先创建配置目录：

mkdir -p config

检查 Compose 配置：

docker compose config

启动服务：

docker compose up -d

这种组合比较适合常见的应用部署：持久化数据交给 Volume 管理，需要手动编辑的配置文件使用 Bind Mount。

六、为什么挂载后原来的文件看不到了？

这是 Docker 挂载比较容易踩坑的地方。

假设镜像内部原本有 /app/config 目录，并且里面已经包含默认配置。

如果使用 Bind Mount 把宿主机的空目录挂载到 /app/config，原来镜像中的文件就会被挂载内容遮住。

这些文件并不一定被删除了，而是当前容器无法通过这个挂载路径直接访问它们。

Volume 还有一个不同的行为：如果将一个空数据卷首次挂载到容器中已经包含文件的目录，Docker 默认可能把目录中原有的文件复制到这个空数据卷。

所以两种挂载方式在首次使用时的表现并不完全相同。

如果应用启动后提示默认配置丢失，首先应检查是否把空的宿主机目录挂载到了原来包含配置的容器路径。

七、挂载目录权限不足怎么办？

有时挂载本身没有问题，但容器内应用读取或写入文件时会出现：

Permission denied

这通常与文件所有者、用户组或访问权限有关。

可以先在宿主机查看：

ls -ld /opt/myapp/data

再查看容器中实际使用的用户身份：

docker exec demo-bind id

Linux 文件权限最终会涉及 UID、GID 和目录访问权限。容器中的用户名和宿主机中的用户名不同，不代表它们一定使用不同的数字 UID。

因此，处理权限问题时，应该先确认容器进程实际使用的 UID、GID，再根据需要调整宿主机目录的所有者或权限。

不建议遇到权限问题就直接执行：

chmod -R 777 /opt/myapp/data

这样虽然可能让程序暂时能够写入，但也会给其他用户开放不必要的访问权限。

另外，Volume 也不是完全没有权限问题。如果镜像使用非 root 用户运行，同样可能需要正确设置数据目录的权限。

八、删除容器时要特别注意数据卷

使用 Docker Compose 时，下面这条命令通常会停止并删除当前项目的容器和相关网络：

docker compose down

但默认不会删除 Compose 声明的命名数据卷。

如果使用：

docker compose down -v

情况就不同了。

这里的 -v 会额外删除 Compose 文件中声明的命名数据卷，以及相关容器附带的匿名数据卷；标记为 external 的数据卷不在这一删除范围内。

对于保存了数据库或其他重要数据的项目，这个参数可能造成数据丢失。

另外，执行：

docker volume prune

也需要谨慎，因为它会清理符合条件的未使用数据卷，其中可能包含暂时没有挂载、但以后仍然需要恢复的数据。

所以在清理 Docker 资源前，最好先检查数据卷是否包含需要保留的内容。

九、数据持久化不等于备份

虽然 Volume 和 Bind Mount 都能让数据在容器删除后继续存在，但它们本身不是完整的备份方案。

例如，应用错误地删除了数据文件，或者宿主机磁盘发生故障，挂载的数据仍然可能丢失。

对于重要业务数据，建议定期备份，并把备份保存在独立的存储位置。

如果是数据库，还需要考虑事务一致性，不能简单认为直接复制正在使用的数据目录就一定能得到可靠备份。

总结

Docker Volume 和 Bind Mount 都能实现数据持久化，但适用场景有所不同。

Volume 更适合交给 Docker 管理的长期数据，Bind Mount 更适合需要直接操作宿主机文件的场景。

实际部署时，建议记住三个原则：

1. 容器中的重要数据应该明确配置持久化挂载。
2. 遇到挂载问题，先检查路径和权限，不要直接设置 777。
3. 删除容器或清理数据卷前，确认数据是否已经备份。

理解这两种挂载方式之后，再使用 Docker Compose 部署数据库、网站或者其他应用，就能更清楚地知道数据到底保存在什么地方，以及容器重建后为什么有些数据仍然存在。