Docker 备份与恢复数据：卷、绑定目录和数据库
容器可以删除和重建，业务数据不能依赖容器可写层。备份前先找出命名卷、绑定目录、Compose 文件、.env 和数据库，再选择与存储类型匹配的方法。
本文是通用方法，不绑定 Ollama、MySQL 或某个业务项目。Ollama 模型目录的项目示例见站内 Docker 部署 Ollama。
2026-09-11 在 Apple silicon macOS、Docker Desktop 4.86.0 和 Engine 29.7.2 环境实测通过命名卷写入、只读挂载归档、恢复到空白新卷和文件读取。数据库 dump、跨主机复制、SELinux 与生产应用恢复仍需按目标项目单独验证。
备份结论
| 数据类型 | 推荐方法 | 恢复重点 |
|---|---|---|
| 命名卷 | 临时工具容器归档 | 恢复到同名或新卷并检查权限 |
| 绑定目录 | tar/文件同步 | 保留目录结构、属主和权限 |
| SQLite | 停止写入后复制数据库和配置 | 先校验文件再启动应用 |
| PostgreSQL/MySQL | 使用原生 dump 工具 | 先恢复数据库，再恢复上传文件 |
| Compose 配置 | 单独归档 compose.yaml、.env | 先运行 docker compose config |
1. 盘点数据边界
docker volume ls
docker volume inspect project_data
docker ps --format 'table {{.Names}}\t{{.Mounts}}'
docker inspect app --format '{{json .Mounts}}'记录每个挂载的源路径、容器路径、卷名和所属服务。镜像本身可重新拉取，镜像备份不能替代业务数据备份。
2. 备份命名卷
先停止会写入卷的服务，避免归档得到不一致快照：
cd /opt/project
docker compose stop app
mkdir -p backups
docker run --rm \
-v project_data:/data:ro \
-v "$PWD/backups:/backup" \
alpine:3.20 \
tar czf "/backup/project-data-$(date +%F).tar.gz" -C /data .
docker compose start app检查归档：
tar tzf backups/project-data-YYYY-MM-DD.tar.gz | head
sha256sum backups/project-data-YYYY-MM-DD.tar.gzproject_data 必须替换为实际卷名；不要把备份目录挂载到待备份卷内部。备份副本应复制到异机或对象存储，并按权限和加密策略保存。
3. 备份绑定目录和配置
cd /opt/project
tar --numeric-owner -czf "backups/project-files-$(date +%F).tar.gz" data uploads compose.yaml .env.env 可能包含密钥，备份文件不得进入公开仓库或聊天记录。若应用持续写入上传目录，先停服务或使用应用提供的快照能力。
4. 数据库备份
数据库不要只复制容器目录。使用数据库原生工具，并单独备份 Compose 配置和上传文件：
# PostgreSQL 示例
docker compose exec -T db pg_dump -U app -d app -Fc > backups/app-$(date +%F).dump
# MySQL 示例
docker compose exec -T db mysqldump -uapp -p app > backups/app-$(date +%F).sql密码应通过容器环境、交互输入或临时凭据注入，避免出现在 Shell 历史。完成后检查 dump 文件可以读取，不能只看命令退出码。
5. 恢复到新卷
危险操作提醒： 恢复会覆盖目标目录；先确认服务已停止、备份日期正确，并在隔离环境演练。恢复命名卷：
cd /opt/project
docker compose stop app
docker volume create project_data_restore
docker run --rm \
-v project_data_restore:/data \
-v "$PWD/backups:/backup:ro" \
alpine:3.20 \
sh -c 'tar xzf /backup/project-data-YYYY-MM-DD.tar.gz -C /data'project_data_restore 应是空白目标卷。检查文件、属主和权限后，再把 Compose 的卷引用切换到该卷并启动服务；不要直接向仍含旧文件的生产卷叠加解压。恢复绑定目录时，把归档解压到确认过的宿主机目录，并核对属主、权限和 SELinux 标签（适用时）。恢复数据库时，先恢复数据库，再恢复文件：
docker compose stop app
docker compose exec -T db pg_restore -U app -d app --clean --if-exists < backups/app-YYYY-MM-DD.dump
docker compose start app--clean 会删除目标数据库对象，只能对确认过的目标执行。
6. 恢复验收
docker compose ps
docker compose logs --tail=100 app
curl -fsS http://127.0.0.1:8080/health登录应用，检查一条已知记录、一个上传文件和关键配置。容器启动成功或 tar 解压成功，都不能证明业务恢复完整；至少保留一次定期恢复演练记录。
安全边界
备份文件可能包含密码、令牌、用户数据和私密配置。限制备份目录权限，传输和异机存储时使用加密，避免把 .env、数据库 dump 或模型文件提交到公开仓库。恢复前确认目标主机、卷名和备份日期，防止覆盖错误环境。
常见问题
备份文件为空或内容不一致
检查服务是否仍在写入，先停止服务或使用数据库原生快照，再重新备份。
恢复后应用没有权限读取文件
检查 docker inspect 的挂载路径、宿主机属主和容器运行用户；按项目文档修正权限，不要直接对整个目录执行 chmod 777。
找不到卷
使用 docker volume ls 和 docker compose config 核对 Compose 项目名前缀。不要凭记忆猜卷名。
建立备份后
设置定期任务、异机副本和保留周期；每次应用升级前做一次数据库和文件备份，升级后在隔离环境验证恢复。
总结
Docker 备份的对象是卷、绑定目录、数据库和配置，而不是容器本身。停止写入、按存储类型选择工具、恢复后检查业务记录，才能把归档文件变成可用的恢复方案。