删除 Docker 容器后，数据是否保留，要看文件实际写在哪里。写进容器可写层的文件会随容器删除；写进独立数据卷或宿主机挂载目录的文件，通常可以继续使用。带上删除卷的选项，结果又会变化。[1][3][4]
对运行数据库、WordPress 或上传服务的服务器，删除前应核对实际挂载、确认数据目录、验证备份。容器能重新启动，并不能证明旧数据已经接回来了。
本文适用于单机 Linux Docker Engine 与 Docker Compose V2，命令使用 docker compose。面板、自定义脚本和集群平台可能额外执行卷清理，操作前需要检查它们实际调用的命令。
先确认数据库和上传文件写到哪里
假设要检查的容器名为 app-db，可先运行这些只读命令：
docker inspect app-db --format '{{json .Mounts}}'
docker inspect app-db --format '{{json .Config.Volumes}}'
docker ps -a --filter name=app-db
.Mounts 显示实际挂载。重点核对 Type、Source、Destination，以及数据卷的 Name。例如，数据库使用 /var/lib/mysql，挂载目标却只有 /backup，数据库文件仍可能留在容器可写层里。具体数据路径必须以镜像文档和应用配置为准。
.Config.Volumes 可以辅助发现镜像或容器声明的卷路径，但不能代替 .Mounts。镜像声明了 VOLUME，而运行命令没有指定来源时，可能使用的是匿名卷。[1]
数据库还需要核对实际配置的数据目录；上传服务则要检查新上传文件的落点。配置文件写着一个路径，程序也可能通过环境变量或启动参数使用另一个路径。
容器可写层、数据卷和目录挂载有什么区别
容器可写层跟着单个容器存在。停止容器一般会保留这层数据，删除容器则会删除可写层。重新使用同一个镜像创建容器，不会把被删除容器的可写层恢复出来。[1]
命名卷由 Docker 管理，有明确名称，例如 site_db_data。它独立于容器存在，移除使用它的容器通常不会删除卷。新容器挂载同一个卷、同一个数据路径后，才有机会继续读取原数据。[1]
匿名卷同样由 Docker 管理，只是名称通常是一串随机标识。它可能在普通容器删除后留下，但新容器不会自动认领原来的匿名卷。旧卷还在、新容器却读到空库，这种情况并不矛盾。[1][3]
**bind mount（目录挂载）**直接把宿主机目录映射到容器内，例如将 /srv/site/uploads 挂到上传目录。移除容器本身通常不会删除宿主机源目录。不过容器对目录默认可能具有写权限，应用或清理脚本仍能删掉里面的文件。[2]
数据卷和挂载目录解决的是容器生命周期与数据分离的问题。磁盘损坏、误写、误删、数据库损坏仍会影响其中的数据，备份需要单独安排。
几条删除命令的影响不同
下面按 Docker 官方命令说明区分，未涵盖运维面板自行添加的清理动作。[3][4]
| 操作 | 容器可写层 | 命名卷 | 匿名卷 | 宿主机挂载目录 |
|---|---|---|---|---|
| 停止容器 | 保留 | 保留 | 保留 | 保留 |
普通 docker rm |
删除 | 保留 | 通常保留 | 源目录保留 |
docker rm -v |
删除 | 保留 | 删除关联匿名卷，仍被使用的卷可能无法移除 | 源目录保留 |
普通 docker compose down |
删除项目容器的可写层 | 默认保留 | 默认保留，但后续 up 不会自动重新挂载旧匿名卷 |
源目录保留 |
docker compose down -v |
删除项目容器的可写层 | 删除 Compose 文件声明的命名卷，external 卷除外 | 删除关联匿名卷 | 源目录保留 |
docker rm -v 与 docker compose down -v 的影响范围不同。前者不会因为指定 -v 就删除命名卷；后者会删除 Compose 文件 volumes 部分声明的命名卷。标记为 external 的卷不会被 Compose 的 down 删除，但仍可能被单独执行的卷删除命令移除。[3][4]
使用 docker run --rm 创建容器时，容器退出后会自动移除，与它关联的匿名卷也会被清理。这个选项适合短期任务，持久业务数据应明确指定保存位置。[1]
涉及删除卷的命令，上表只用于说明行为。生产环境执行前必须先确认卷的用途和备份，不能从“更新容器”的需求直接推导出“删除数据卷”的操作。
Compose 重建后出现空数据库，先核对卷名
下面是单机数据库服务的数据挂载片段，需合并进现有 Compose 文件。镜像、账号、密码、端口与资源配置应继续使用已经验证的方案，不要把这个片段当成完整部署文件。
services:
db:
volumes:
- db_data:/var/lib/mysql
volumes:
db_data:
这类卷的实际名称通常包含 Compose 项目名前缀。迁移目录、改变 -p 参数或修改项目名后，可能使用另一个实际卷名。Docker 创建了新卷，数据库就会按新环境初始化。[1][5]
在重建前保存实际挂载信息，重建后再核对：
docker compose config
docker compose ps -a
docker volume ls
docker volume inspect site_db_data
site_db_data 只是示例，必须替换为 .Mounts 中查到的实际名称。docker compose config 可能显示解析后的敏感配置，输出只保存在受控位置，分享前遮盖密码和令牌。
如果卷由你预先创建并单独管理，可以在 Compose 中明确引用：
services:
db:
volumes:
- db_data:/var/lib/mysql
volumes:
db_data:
external: true
name: site_db_data
执行前确认 site_db_data 确实存在且属于这个数据库。external 卷不会由 Compose 自动创建，也不属于 down -v 的删除范围。给现有配置增加这一段前，应先核对当前卷名；名称填错仍可能导致启动失败或挂载错误数据。[3][5]
文件突然不见了，也可能被挂载遮住
把数据卷或宿主机目录挂载到容器中已有文件的路径，会遮住原路径的内容。bind mount 指向空目录时，容器里原先可见的文件可能看起来消失了。这不能直接证明原文件已经删除。[1][2]
空数据卷还涉及初始化行为：默认情况下，容器目标目录已有的内容会复制到新空卷中；bind mount 不会按同样规则填充宿主机目录，volume-nocopy 选项也会改变卷的复制行为。[1][2]
遇到“旧文件不见、新目录为空”，应先检查实际源路径和卷名，再判断是挂载遮蔽、创建了新卷、权限不足，还是文件已被删除。不要用删除卷来尝试让旧内容出现。
删除前留证据，备份后验证恢复
删除前至少保存容器挂载信息、Compose 配置、实际卷名、宿主机源路径以及正在运行的镜像版本。Linux 路径和权限差异、运行用户的 UID/GID，也会影响新容器能否访问原文件。[1][2]
普通文件目录可在暂停写入后备份，并核对文件数量、关键文件校验值和权限。数据库需要使用该数据库支持的逻辑备份或一致性备份方式。直接打包运行中的数据库数据目录，不能保证得到可用备份。
恢复验证应在隔离测试环境中进行。使用兼容版本启动，核对表、业务记录和上传文件，再验证应用读取、写入与日志。不要让两个数据库进程同时读写同一份数据目录。本文没有在读者服务器上实测，示例需要结合实际镜像、目录与业务维护窗口调整。
容器已经删除、但卷仍存在时，先保留卷名和检查结果，确认备份后再规划恢复。如果卷也被删除，或者数据只存在于已删除容器的可写层，重新拉取镜像和重新创建容器无法补回业务数据；恢复要依赖此前的备份、快照或专业恢复方案。
一次容器更新怎样算验收通过
更新前记录数据落点，更新后检查新容器挂载的 Source 与 Destination 是否符合预期。数据库需要核对关键记录，上传服务需要实际打开旧文件，并确认新文件写入预期目录。
卷仍存在、容器正常运行、接口可访问，是不同的检查项。只有旧业务数据可读、新数据可写、重启后仍能正确挂载，才算完成这次数据持久化验证。
官方参考资料
资料核验日期：2026 年 10 月 14 日。以下命令行为根据 Docker 官方文档核对。
[1] Docker Engine：Volumes — https://docs.docker.com/engine/storage/volumes/
[2] Docker Engine：Bind mounts — https://docs.docker.com/engine/storage/bind-mounts/
[3] Docker CLI：docker compose down — https://docs.docker.com/reference/cli/docker/compose/down/
[4] Docker CLI：docker container rm — https://docs.docker.com/reference/cli/docker/container/rm/
[5] Docker Compose：Volumes attribute — https://docs.docker.com/reference/compose-file/volumes/