说到 Docker， 很多人第一反应就是「轻量、快速、易部署」——这的确是它的核心卖点。但如果你曾经在容器里玩过数据库或文件服务， 层次低了。 肯定会体会到一个令人揪心的痛点：容器一旦被删除，里面的数据也跟着消失。在生产环境里这种「一闪即逝」的特性根本无法接受。

不堪入目。 别慌！下面这篇文章从最基础的概念讲起，一路带你玩转 Ubuntu 上的 Docker 持久化方案。我们会用实际命令、对比表格以及真实案例，让你在阅读完后立刻能把数据平安锁进宿主机。

一、为什么容器里的数据会「蒸发」？

Docker 的设计哲学是「容器即进程」。当你施行 docker run 时Docker 会在一个临时的文件系统上启动你的镜像。这个文件系统默认是只读层 + 可写层，随时可以被抛弃，盘它。。

从头再来。 换句话说 如果没有额外指令告诉 Docker 「把这些东西保存到外部」，所有写入操作都会停留在可写层，而这层只存在于容器的生命周期内。

二、 持久化的两大法宝：卷和绑定挂载

来一波... 下面这张表格把两者的核心区别列得清清楚楚，你可以直接对照自己的需求挑选：

特性	Docker Volume	Bind Mount
创建方式	docker volume create mydata	mkdir -p /srv/docker/data && docker run -v /srv/docker/data:/app/data …
管理便利性	Docker 本身提供查询、备份、迁移 API； docker volume ls / inspect / prune	完全依赖宿主机文件系统，需要自行维护权限和路径。
性能表现	在多数 Linux 环境下几乎无差别，但在 macOS/Windows 上有额外抽象层。	直接映射宿主机目录，IO 直通；但若宿主机是网络文件系统可能出现延迟。
平安性 & 隔离度	仅对 Docker 可见，默认不暴露给宿主机用户。	任何拥有宿主机路径访问权的人都能直接读写。
适用场景	- 数据库 - 应用需要跨容器共享 - 想要利用 Docker 自带备份机制	- 开发调试阶段需要实时编辑代码 - 与已有业务系统共享同一目录 - 需要手动管理快照或版本控制的场景

三、 一步步搞定 Volume 持久化——以 MySQL 为例

创建专属卷并检查状态

# 创建名为 mysql_data 的卷
docker volume create mysql_data
# 查看已有卷列表
docker volume ls
# 详细信息
docker volume inspect mysql_data

TIPS：卷名最好遵循业务前缀，比方说{项目名}_data_{日期}, 方便后期审计。

用卷启动 MySQL 容器并映射端口

# 拉取官方镜像
docker pull mysql:8.0
# 启动容器
docker run -d \
  --name my_mysql \
  -e MYSQL_ROOT_PASSWORD=SuperSecret! \
  -v mysql_data:/var/lib/mysql \
  -p 3306:3306 \
  mysql:8.0

这里我们把 MySQL 的数据目录/var/lib/mysql映射到了刚才创建的卷mysql_data. 从此以后即使你施行docker rm -f my_mysql && docker run …​ , 数据仍然安然无恙，归根结底。。

验证持久化效果——重启容器后再查一次数据表结构：

# 首次登录
docker exec -it my_mysql mysql -uroot -pSuperSecret! -e "CREATE DATABASE demo; USE demo; CREATE TABLE t;"
# 删除容器
docker rm -f my_mysql
# 
基于同一卷启动
docker run -d \
  --name my_mysql2 \
  -e MYSQL_ROOT_PASSWORD=SuperSecret! \
  -v mysql_data:/var/lib/mysql \
  -p 3307:3306 \
  mysql:8.0
# 检查表是否仍在
docker exec -it my_mysql2 mysql -uroot -pSuperSecret! -e "USE demo; SHOW TABLES;"

摆烂。 If you see table “t”, congratulations! The data survived container death.

四、 Bind Mount 实战——把网站日志永久保存到宿主机目录中

准备宿主机目录并赋予合适权限

# 创建目录
mkdir -p /var/log/nginx-data
# 给 www-data 用户读写权限
chown -R www-data:www-data /var/log/nginx-data
chmod 750 /var/log/nginx-data

小提醒：Nginx 在容器里默认以www-data )运行，如果宿主机上 uid 不匹配，会出现“Permission denied”。可以通过-u $:$` 参数统一 UID/GID，物超所值。。

启动 Nginx 并绑定日志目录到本地路径

# 拉取官方镜像
docker pull nginx:stable
# 启动并挂载日志目录
docker run -d \
   --name web_server \
   -v /etc/nginx/conf.d:/etc/nginx/conf.d:ro \   # 配置只读挂载
   -v /var/log/nginx-data:/var/log/nginx \     # 日志双向同步
   -p 8080:80 \
   nginx:stable

The logs generated inside container now appear instantly under /var/log/nginx-data 换个思路。 /…​ . Even if you delete and recreate container, your historic logs stay untouched.

快速检查日志是否实时更新：

# 发起一次请求触发日志写入
curl http://localhost:8080
# 查看本地日志文件是否新增条目
tail -n 5 /var/log/nginx-data/access.log

五、备份与恢复——别让意外成为灾难根源！

A well‑designed持久化方案离不开定期备份。下面分别演示对 Volume 与 Bind Mount 的备份方式。

卷备份：利用 tar 打包整个卷内容

# 停止使用该卷的所有容器， 以免写入冲突
docker stop my_mysql
# 临时挂载卷到一个临时容器，只做拷贝工作 
docker run --rm \
   -v mysql_data:/data \
   alpine tar czf /backup/mysql_data_$.tar.gz -C /data . 
# 把生成的压缩包复制到本地平安位置 
docker cp $:/backup/mysql_data_$.tar.gz ~/backups/

This method gives you a portable snapshot that can be restored on any host supporting Docker.，没耳听。

Bind Mount 的传统文件系统备份

# 使用 rsync 增量备份，本地目录同步到远程 NAS 
rsync -avz --delete /var/log/nginx-data/ :/mnt/backup/nginx/
# 若想打包归档，可直接 tar 
tar czf ~/backups/nginx_logs_$.tar.gz /var/log/nginx-data

六、实战经验 & 常见坑点

• 权限误区：If you mount a host directory that belongs to root into a container running as non‑root, writes will silently fail. Always align UID/GID or use  :z/:Z ` SELinux 标签来解决冲突。
.
• 磁盘空间监控：The host’s disk can fill up quickly when logs or databases grow unchecked. 配合
.
• 跨平台迁移：If you计划把同一套 Compose 文件从开发机器搬到生产服务器， 请优先使用 Volume，主要原因是它们是抽象层，无需担心宿主机路径差异导致启动失败。
.
• 快照策略：Docker 本身不提供快照功能， 但配合 LVM 或 ZFS 可以实现瞬间冻结整个 Volume，然后再进行远程复制，实现 RPO 为秒级别的大保单方案。
. * 小技巧：给所有重要 Volumes 打上统一标签， 比方说 `project=shop`，以后通过 `docker volume ls --filter label=project=shop` 快速定位相关资源。
• 调试技巧：A lot of times people think data didn't persist because y looked at wrong path inside container. Use `docker inspect` to confirm exact mount point mapping:
.

# 查看挂载详情 
docker inspect my_mysql | grep \"Mounts\" –A5 –B5 
# 输出示例 
"Source": "/var/lib/docker/volumes/mysql_data/_data", 
"Destination": "/var/lib/mysql"
...
这个输出能帮助你快速定位真实物理路径，从而排除「看错了」这种尴尬。
平安加固：If your service stores敏感信息， 请考虑开启加密插件或将 Volume 放在加密磁盘分区上；一边限制宿主机用户组对挂载路径的访问范围，仅允许可信 CI/CD runner 写入。
.
 

七、 ：让持久化不再是难题，而是自只是然的一步操作 🎉

Cake is sweet, but losing data is bitter—特别是在生产线上。只要记住「永远不要把重要数据留在裸露的可写层」， 配合本文提供的两套实践方案，你就可以轻松做到「部署即永续」：Volume 为正式环境提供可靠隔离与便捷管理； 欧了！ Bind Mount 则为开发调试提供实时编辑能力。再加上一套完善的备份脚本，你再也不用为「突然找不到数据库」而抓狂了。

---

©2026 技术分享站 | 本文仅用于学习交流， 如有侵权请联系删除 作者：技术小白   来源：原创撰写 | 更新于2026‑05‑16

---