基本命令#

1
# 创建一个命名卷
2
docker volume create mydata
3

4
# 列出所有卷
5
docker volume ls
6

7
# 看某个卷的详情（挂载点、创建时间、被哪些容器用）
8
docker volume inspect mydata
9

10
# 删除一个卷（必须先停掉并删除使用它的容器）
11
docker volume rm mydata
12

13
# 清理所有没有容器在用的卷（危险，见下方警告）
14
docker volume prune

WARNING

docker volume prune 和 docker system prune 一样是「一键后悔药没有」类命令：它会删掉所有当前没有容器引用的卷——包括你只是暂时把容器删了、打算一会儿重建后继续用的卷。执行前务必确认里面没有要留的数据。日常清理宁可手动 docker volume rm 一个个来。

卷在磁盘上的真实位置#

命名卷的数据实际存放在宿主机：

1
/var/lib/docker/volumes/<卷名>/_data/

比如卷 mydata 的内容就在 /var/lib/docker/volumes/mydata/_data/ 里。知道这个位置是为了排障时能看一眼里面有什么，但不建议直接去改这个目录：

1. Docker 假定这个目录只有它自己在管，你绕过它直接增删文件，权限和属主很容易被写歪，容器里再访问就报错；
2. 容器运行中直接改，应用层面的缓存和锁完全不知情，数据一致性没保证；
3. 有些存储驱动下这个路径并不长这样（比如用了远程卷插件），按路径操作的代码不可移植。

正确姿势永远是：通过容器去读写卷——下面的备份和恢复都是这么做的。

Compose 里怎么声明#

1
services:
2
  db:
3
    image: postgres:16
4
    environment:
5
      - POSTGRES_PASSWORD=example
6
    volumes:
7
      - db_data:/var/lib/postgresql/data   # 短语法：卷名:容器内路径
8

9
volumes:
10
  db_data:        # 顶层 volumes 段：声明本项目用到的命名卷

注意一个关键细节：Compose 创建的卷名会带项目名前缀。假设项目名（目录名）是 myapp，你在文件里写的 db_data，真实卷名是 myapp_db_data。用 docker volume ls 看到带前缀的卷别慌，那不是多出来的野卷子。排障一节会讲这个前缀带来的经典问题和解法。

只读挂载和绑定挂载的写法也顺带记住：

1
    volumes:
2
      - db_data:/var/lib/postgresql/data        # 可读写（默认）
3
      - ./config:/etc/myapp/config:ro           # 绑定挂载 + 只读

坑一：宿主机路径不存在时#

docker run -v /host/path:/data ... 时如果 /host/path 不存在，Docker 会自动以 root 身份创建一个空目录。你以为挂的是自己准备好的目录，其实挂了个空的，应用写进去的数据落在一个 root 属主的陌生目录里。Compose 的短语法同样如此。用长语法可以明确禁止这种行为：

1
    volumes:
2
      - type: bind
3
        source: ./config
4
        target: /etc/myapp/config
5
        read_only: true
6
        bind:
7
          create_host_path: false   # 路径不存在就直接报错，而不是偷偷新建

坑二：属主与容器内 uid 对不上（最经典）#

容器里的进程用什么 uid 运行，取决于镜像，常见情况：

• 官方 postgres 镜像里 postgres 用户是 uid 999；
• nginx 镜像 worker 进程是 uid 101；
• 很多镜像默认直接用 root（uid 0）。

绑定挂载不会做任何 uid 转换：宿主机上属主是 uid 1000 的文件，进了容器就还是 uid 1000。于是经典报错就来了——容器内进程是 uid 999，宿主机目录属主是 1000 且权限 755，进程没有写权限，直接 Permission denied 起不来。

排查和处理：

1
# 查宿主机上自己的 uid/gid
2
id
3

4
# 查目录现在的属主（显示数字 uid/gid）
5
ls -n /srv/myapp/data
6

7
# 把目录属主改成容器内进程需要的 uid（例：999）
8
sudo chown -R 999:999 /srv/myapp/data

两个原则：

1. 不要无脑 chmod 777。777 能「解决」权限问题，也能让任何进程随便写你的数据，只是把报错换成了安全隐患。
2. 能选的话优先用命名卷：Docker 创建卷时会把卷目录的属主初始化为镜像里对应路径的属主，上面这个坑基本不会出现——这也是数据库类服务推荐命名卷的原因之一。

坑三：只读挂载 :ro#

还有个写法上的细节：Compose 里绑定挂载用 ./config 这种相对路径时，它是相对于 Compose 文件所在目录解析的，不是你执行命令时所在的目录。项目目录搬家时绑定挂载会跟着 Compose 文件走，这通常正是你想要的；但如果在别的目录用 -f 指定 Compose 文件，就要意识到相对路径的锚点也随之变了，排障时先确认锚点再怀疑文件丢了。

配置文件类挂载建议一律加 :ro：

1
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

容器被攻破时写不进配置，也改不了你的站点文件，属于零成本的安全加固。注意 :ro 只约束容器这一侧，宿主机上你自己照样能改。

路线一：逻辑导出（推荐，热备）#

用数据库自带的导出工具，得到的是一致的逻辑备份，服务不用停：

1
# PostgreSQL：导出为 SQL 文本
2
docker compose exec db pg_dump -U postgres myapp > ~/backups/mydb-$(date +%F).sql
3

4
# MySQL：--single-transaction 保证导出期间一致性且不锁表
5
docker compose exec db mysqldump -u root -p密码 --single-transaction myapp > ~/backups/mydb-$(date +%F).sql

恢复时反过来喂回去：

1
# PostgreSQL
2
cat ~/backups/mydb-2026-11-15.sql | docker compose exec -T db psql -U postgres myapp
3

4
# MySQL
5
cat ~/backups/mydb-2026-11-15.sql | docker compose exec -T db mysql -u root -p密码 myapp

逻辑导出的额外好处：跨版本、跨机器恢复都兼容（卷文件直接拷则不行，老版本的数据文件新版本可能拒绝加载）。

路线二：停机冷备（简单粗暴但可靠）#

能接受短暂停机的个人服务，直接停掉数据库再打包数据卷，文件处于静止状态，一致性天然成立：

1
docker compose stop db
2
docker run --rm -v myapp_db_data:/data:ro -v ~/backups:/backup alpine \
3
  tar czf /backup/db_data-cold-$(date +%F).tar.gz -C /data .
4
docker compose start db

在 Compose 项目里固化成一条命令#

把逻辑导出写进一个小脚本放项目里（比如 backup.sh），手动和定时任务都能调：

1
#!/bin/bash
2
set -e
3
mkdir -p ./backups
4
docker compose exec -T db pg_dump -U postgres myapp > ./backups/mydb-$(date +%F).sql
5
echo "备份完成：./backups/mydb-$(date +%F).sql"

注意 docker compose exec 在脚本里要加 -T（不分配伪终端），否则在 cron 这类非交互环境里会报错。

WARNING

还有一个隐蔽坑：pg_dump 出来的备份只包含数据库内容，不包含数据库的用户/角色等全局对象。要全量兜底可以用 pg_dumpall（整实例导出）。个人项目多数只用默认用户，知道有这回事即可，真迁移整实例时再换 pg_dumpall。

第一步（旧机）：停服并打包项目目录#

先停服务，保证打包期间文件不再变化：

1
cd /opt/myapp
2
docker compose down

注意是 down 不是 down -v——-v 会把命名卷一起删掉，迁移现场千万别顺手加上。

打包整个项目目录（compose 文件、.env、绑定挂载的配置和数据都在里面）：

1
tar czf ~/myapp-dir-$(date +%F).tar.gz -C /opt myapp

WARNING

.env 文件里通常有数据库密码、密钥等敏感信息，它会被打进这个包。传输和存放时按敏感文件对待：只走加密通道（scp/rsync over SSH 本身是加密的）、别丢到任何公共网盘或公开仓库。

第二步（旧机）：打包数据卷 + 导出数据库#

命名卷逐个按前面的标准做法打包：

1
mkdir -p ~/backups
2
docker run --rm -v myapp_db_data:/data:ro -v ~/backups:/backup alpine \
3
  tar czf /backup/myapp_db_data-$(date +%F).tar.gz -C /data .

数据库额外再做一份逻辑导出，双保险（卷包用于整卷还原，SQL 用于卷还原出问题时兜底）。逻辑导出要在停机前做，所以实际操作顺序是：先 pg_dump → 再 docker compose down → 再打目录包和卷包：

1
docker compose exec -T db pg_dump -U postgres myapp > ~/backups/mydb-$(date +%F).sql

记录镜像清单，到了新机好核对拉的版本对不对：

1
docker compose images > ~/backups/images-list.txt
2
cat ~/backups/images-list.txt

第三步：传输到新机#

1
# rsync 断点续传，大文件更稳
2
rsync -avz -e ssh ~/myapp-dir-*.tar.gz ~/backups/ root@新机IP:~/migrate/
3

4
# 或者简单粗暴 scp
5
scp ~/myapp-dir-*.tar.gz ~/backups/*.tar.gz ~/backups/*.sql root@新机IP:~/migrate/

第四步（新机）：装 Docker 并放回目录#

新机先按 《如何在Linux部署Docker&Compose》 装好 Docker，然后：

1
mkdir -p ~/migrate && cd ~/migrate   # 假设安装包都传到了这里
2

3
# 放回项目目录
4
tar xzf myapp-dir-*.tar.gz -C /opt
5
cd /opt/myapp
6
ls -la   # 确认 docker-compose.yml 和 .env 都在

第五步（新机）：逐卷恢复#

在启动服务之前先建卷并灌数据。注意：卷名必须和 Compose 将要使用的完全一致（带项目名前缀 myapp_db_data）：

1
docker volume create myapp_db_data
2
docker run --rm -v myapp_db_data:/data -v ~/migrate:/backup alpine \
3
  tar xzf /backup/myapp_db_data-*.tar.gz -C /data
4
docker run --rm -v myapp_db_data:/data alpine ls -la /data   # 验一眼

然后告诉 Compose「这个卷是现成的，别自己新建」——在顶层 volumes 段给它标 external: true：

1
volumes:
2
  db_data:
3
    external: true
4
    name: myapp_db_data

为什么需要这一步、忘了会怎样，排障一节细说。

第六步（新机）：启动并按清单验证#

1
cd /opt/myapp
2
docker compose up -d
3
docker compose ps        # 所有服务都是 Up
4
docker compose logs -f   # 看一遍启动日志，有没有连不上数据库之类的报错

最后逐项过验证清单，三查缺一不可：

DNS 切换有个时间差：建议迁移前一天先把域名 TTL 调小（比如 300 秒），切换当天生效快、回滚也快。全部验证通过、观察一两天没问题之后，再去注销旧机——旧机就是你最后的回滚方案，别急着删。

回滚预案也要在动手前想好：如果新机验证不过，最快的回滚就是把 DNS 解析切回旧机 IP（旧机在整个过程中只是停了服务、数据原封未动，切回后 docker compose up -d 即可恢复）。所以迁移的正确心态是：旧机全程只读冻结、新机随便折腾，任何一步不对劲都能全身而退。等新机稳定运行几天、且在新机上已经产生了一份新备份之后，旧机才算完成历史使命。

恢复后服务起不来，日志报 Permission denied#

九成是属主问题：备份打包或解包时如果没在容器里用 tar 而是手动 cp，或者解包工具没保留属主，文件会变成 root 或错误 uid 所有，应用进程（比如 uid 999 的 postgres）读不了自己的数据目录。

1
# 对比原卷属主：看数据目录里的文件是谁的
2
docker run --rm -v myapp_db_data:/data alpine ls -ln /data
3

4
# 典型修复：把属主改回应用需要的 uid（以 PostgreSQL 的 999 为例）
5
docker run --rm -v myapp_db_data:/data alpine chown -R 999:999 /data

根治办法是全程用本文的 tar 流程（tar 默认保留 uid/gid），别混用别的方法搬数据。

卷名对不上：Compose 新建了一个空卷，数据「消失」了#

现象：迁移后服务能起来，但里面是全新空数据；docker volume ls 里躺着两个长得像的卷。

原因就是前面说的项目名前缀：你在旧机手工建的卷叫 db_data，而 Compose 按项目名拼出来的真实卷名是 myapp_db_data，两者不是一个卷。Compose 找不到自己要的卷，就默默新建了一个空的。

解法二选一：

1
# 解法一（推荐）：顶层 volumes 段声明用现成的卷
2
volumes:
3
  db_data:
4
    external: true
5
    name: myapp_db_data     # 写真实卷名

1
# 解法二：建卷时就直接用 Compose 期望的名字
2
# 即一开始就 docker volume create myapp_db_data 并往里恢复，
3
# Compose 发现同名卷已存在会直接使用

排查时先 docker volume ls 对一眼名字，能省下大量瞎猜的时间。

备份包解开多了一层目录#

现象：恢复完进卷一看，数据不在 /data 根下，而是躺在 /data/data/ 里，应用自然读不到。

原因：打包时写的是 tar czf ... /data（打了目录本身），包里所有路径都带个 data/ 前缀；解到 /data 就成了套娃。本文备份命令用的是 -C /data .（打目录里的内容），从源头避开这个问题。

如果手上的旧包已经是带目录层的，恢复时用 --strip-components 削掉一层补救：

1
docker run --rm -v myapp_db_data:/data -v ~/backups:/backup alpine \
2
  tar xzf /backup/旧包.tar.gz -C /data --strip-components 1

打包到一半失败：no space left on device#

备份本质是「读一份、再写一份」，目标磁盘至少要留出比源数据更大的空闲空间（压缩后通常会小不少，但日志、媒体这类已经压缩过的数据几乎压不动，要按原体积预估）。先用 docker system df -v 确认卷的实际大小，再 df -h 看备份目录所在磁盘的余量。空间实在紧张时，可以让 tar 直接通过管道交给 gzip 以上的压缩，或者把备份目录挂到另一块盘上，但别把备份打到和源卷同一块快满的盘上自欺欺人。

卷删不掉：volume is in use#

docker volume rm 报在用，先查是谁在用：

1
docker ps -a --filter volume=myapp_db_data

停掉的容器也算「在用」，把对应容器 docker rm 后再删卷。确认里面数据真的不要了再动手。