前阵子一台 Ubuntu 服务器频繁告警df -h一看根分区直接飘红可用空间只剩几个 G。排查了一圈发现罪魁祸首是之前为了跑一个知识库 Demo 部署的 RAGFlow——一套 Docker 编排拉起来mysql、minio、es、redis 全在里面镜像加数据卷轻轻松松吃掉三四十 G。如果你也遇到“ubuntu 空间不够了想删掉 RAGFlow”这种问题这篇文章就是给你准备的从空间诊断、容器生命周期清理到数据卷的取舍一步不落拆开讲。先说结论RAGFlow 的删除不是一个docker rm就完事的事它涉及容器、镜像、卷、网络、源码目录五个层面。很多人只删了容器镜像和数据卷还躺在磁盘上空间根本没释放多少。这篇文章我会按“查出空间去哪了 → 清理容器和镜像 → 按需处理数据卷 → 清理残留目录 → 复检空间”这个顺序来中间会穿插我实操时踩过的坑和排查技巧。1. 分清 RAGFlow 的占用构成1.1 为什么 RAGFlow 特别“吃”磁盘RAGFlow 是一个完整的 RAG 知识库系统它不是一个单容器服务而是由多个组件协同工作的容器集群。官方部署方式默认用docker compose一次拉起所有服务。这些服务包括但不限于RAGFlow 核心 API 服务RAGFlow Web 前端服务后台任务执行 WorkerMySQL存元数据MinIO存对象数据Elasticsearch存向量索引Redis做缓存和消息队列每个组件对应一个独立的 Docker 镜像镜像之间还有多层叠加。一套下来镜像体积通常在 8-12 G 左右如果系统里还留有历史版本的镜像甚至能堆到二十多 G。数据卷是另一个大头。RAGFlow 默认会为 MySQL、MinIO、Elasticsearch 创建数据卷这些卷会随着 ingestion 文档数量、向量化索引规模、文档切块数量不断膨胀。我实测过往库里灌几百份 PDF 之后es 卷和 minio 卷合起来能到 15-20 G。文档被解析后的切片、图片、表格都会存在 minio 里es 里还要存向量和倒排索引。所以“空间不够”这件事本质是镜像层和数据卷层两方面共同造成的。只删容器不删镜像只删镜像不删卷空间都释放不到位。1.2 初步空间诊断用 docker system df 快速定位动手删除之前先搞清楚空间到底被谁吃了。盲目删要是有别的服务在跑容易误伤。我习惯先跑docker system df这条命令会列出 Docker 在磁盘上的资源占用概览包括镜像、容器、本地卷、构建缓存各自的体积还会标出可回收多少。输出大概长这样TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 3 1 11.42GB 9.8GB (85%) Containers 2 1 1.2GB 1.1GB (91%) Local Volumes 5 1 18.7GB 16.5GB (88%) Build Cache 0 0 0B 0B看到Local Volumes那一栏的 SIZE 很大基本就能确认数据卷是空间大户。此时再配合df -h确认分区使用率以及ncdu或者du -sh /var/lib/docker查看 docker 目录的具体体积。另外RAGFlow 的安装目录也要注意。如果你是按照官方文档源码方式部署的项目源码一般放在/root/ragflow或者/home/xxx/ragflow里面除了代码还有日志、临时缓存之类也占空间。后面我们要单独处理。提示docker system df -v可以进入详细视图能看到每个卷、每个容器的具体占用排查时很有用。2. 容器层清理先停后删按依赖顺序来2.1 找到 RAGFlow 的容器集合RAGFlow 部署时日志会明确指出当前注册了自己的容器。最稳妥的判断方式是看容器名称的前缀或者标签。官方 compose 文件里服务名是ragflow容器启动后名称通常是ragflow-server、ragflow-mysql之类的组合或者在容器列表里能看到com.docker.compose.projectragflow这个标签。查找命令docker ps -a --filter nameragflow或者更精确一点通过 compose 项目标签找docker ps -a --filter labelcom.docker.compose.projectragflow如果当时部署时修改过项目名比如docker compose -p myrag up -d那标签里的值就是myrag需要自己对应调整一下。遇到识别不出来容器归属的情况可以用docker inspect看容器的镜像名比如docker inspect 容器ID --format {{.Config.Image}}镜像名里带ragflow的那就是它。2.2 执行删除操作的顺序Docker 删除容器有个依赖关系问题虽然强制删也能删掉但正常还是先停掉所有 RAGFlow 容器再删除避免出现资源占用或者网络残留问题。进入 RAGFlow 源码目录直接一条命令搞定docker compose down这条命令会读取当前目录下的docker-compose.yml停止并删除文件里定义的所有容器同时删除默认创建的 compose 网络。如果当初使用了-p参数指定了自定义项目名要加-p保持一致docker compose -p myrag down如果手头没有源码目录或者 compose 文件已经不在那就只能逐个容器手动处理。先用容器名列表查出来再批量停删docker stop $(docker ps -q --filter nameragflow) docker rm $(docker ps -aq --filter nameragflow)注意--filter匹配的是子字符串所以nameragflow也会匹配到ragflow-mysql这类名称。如果系统里恰好有别的应用名称也带 ragflow谨慎起见还是通过 label 过滤更安全。这块有个我踩过的坑docker compose down默认不会删除数据卷。很多人以为执行完 down 就彻底清干净了结果docker system df一看Local Volumes 部分照旧占了几十个 G。官方命令里需要加-v才会连卷一起删但这里我不建议立即加-v因为数据卷的取舍是有讲究的这一点后面单独展开。3. 镜像层清理把历史镜像一并处理3.1 批量移除 RAGFlow 相关镜像容器删完后镜像本身还占着磁盘。镜像的删除逻辑是只要有一个容器引用它就不能删。所以必须先删容器再删镜像这个顺序错了会报image is being used by running container之类的错误。删除镜像最直接的办法是用docker images找出来然后逐个docker rmi。RAGFlow 官网的镜像一般存放在 Docker Hub 上镜像名是infiniflow/ragflow这个格式加上版本 tag比如infiniflow/ragflow:v0.15.1、infiniflow/ragflow:v0.17.0等。你可以按名字过滤出来统一删docker images | grep infiniflow docker rmi $(docker images -q --filter referenceinfiniflow/*)还需要留意依赖镜像比如 MySQL、MinIO、Elasticsearch 这些中间件镜像。如果同一台机器上还有别的服务在用 MySQL 镜像那这个镜像删掉会影响别的服务需要先确认没有共同占用。最稳的方案是先docker image ls看一遍区分哪些是 RAGFlow 特有的比如 infiniflow/ragflow 本体哪些是通用中间件可能被复用的。RAGFlow 的镜像可以放心删中间件镜像按需处理。3.2 用删除悬空镜像回收零头除了 RAGFlow 本体镜像构建过程中还会产生一些none:none的悬空镜像这些是历史构建层不显示名字但占用磁盘。执行docker image prune可以清理掉所有悬空镜像释放一部分冗余空间。如果想更彻底用docker system prune它会一次清理停止的容器、未被使用的网络、悬空镜像和构建缓存。但这个命令默认不会清理数据卷也不会清理还在使用的镜像所以比较安全。不过执行docker system prune之前最好先看一眼哪些容器是“停止状态”但你可能之后还要重新启动的比如某些还没完成迁移的服务容器。如果你只是想删 RAGFlow那这些容器删掉本来就属于预期内直接跑没问题。注意docker system prune -a --volumes这条命令威力很大会在清理悬空镜像的基础上额外删除所有未被任何容器引用的数据卷慎用。若不加判断地在这台机器上执行可能把其他项目的数据卷一并端了。4. 数据卷层别急着删先想清楚4.1 数据卷与容器生命周期解耦Docker 的数据卷是独立于容器存在的。容器删除、镜像删除都不会自动删除数据卷除非显式加-v参数。这是 Docker 故意设计的机制目的是持久化数据让容器重建时数据不丢。RAGFlow 会用到的数据卷大致有这几类数据卷用途对应服务数据内容MySQL 数据卷ragflow-mysql文档元数据、知识库配置信息MinIO 数据卷ragflow-minio原始文档、切块后的图片和表格等对象存储Elasticsearch 数据卷ragflow-es向量索引、倒排索引、搜索结果缓存Redis 数据卷ragflow-redis缓存数据通常可以丢如果你确认这个 RAGFlow 不再使用而且里面的知识库数据也不需要保留那数据卷可以直接删空间释放效果立竿见影。我的建议是删之前先问自己三个问题这个环境是测试环境还是生产环境知识库里的文档源文件有没有在本地备份删掉之后如果以后还要重新部署能不能接受从零开始重建知识库如果三个问题都指向“可以丢”那就放心删。如果答案里有任何犹豫建议先备份卷数据或者用docker run单独把卷里的文件拷贝出来。4.2 确认数据卷名称并逐一删除先列出所有卷docker volume lsRAGFlow 通过 compose 创建的卷命名规则一般是“项目名_卷名”这种格式比如ragflow_mysql_data、ragflow_minio_data、ragflow_es_data之类。如果项目名是myrag卷名前缀就是myrag_。确认这些卷确实属于 RAGFlow 后执行删除docker volume rm ragflow_mysql_data ragflow_minio_data ragflow_es_data ragflow_redis_data如果你用的是镜像的默认 Volume 定义卷名可能是一长串随机 hash这时可以根据 docker inspect 的数据卷映射关系来定位或者直接按数据卷大小判断哪个是哪个docker system df -v这个详细视图会列出每个卷的名称、大小、被哪些容器使用非常直观。卷的大小一列出来哪个是空间大户一目了然。我处理过一次比较尴尬的情况RAGFlow 里存了挺多测试文档es 卷 13 Gminio 卷 8 Gmysql 卷 2 G。我原本以为用户只需要删容器但保留数据所以执行了docker compose down再重新docker compose up -d。结果 compose 里的卷声明是 external 还是自动创建的方式不一样新起的容器直接挂到了新生成的卷上旧的卷变成了“孤儿卷”没人挂载。过了一个月用户回来说旧数据都不见了但空间更紧张了。后来我才意识到那次的旧卷还在磁盘里躺着但新服务已经不再挂载它等于白白占着空间又访问不到。这件事给我的教训是搞清卷的挂载关系再操作比快速执行命令更重要。新容器会默认创建“新卷”如果你想保留数据重建时必须显式指定外部卷挂载否则数据对不上。5. 源码目录与日志残留处理5.1 删除 RAGFlow 源码目录RAGFlow 的源码目录没有 Docker 相关约束但很多用户在部署第二步时会把整个项目仓库 clone 到服务器上目录下包括代码、Dockerfile、日志、模型缓存、临时解析文件等。我的习惯是这样先看部署目录再动手先别急着删。du -sh /root/ragflow如果目录下包含.git目录整个仓库的历史版本信息都在里面可能占几百 M 到几个 G。如果还跑过docker compose up -d还会生成日志输出文件。如果确认不需要保留源码和配置比如以后还要换一种部署方式直接rm -rf /root/ragflow但如果你觉得之后可能还会再部署 RAGFlow可以把源码目录保留下来仅删掉数据缓存和日志文件。源码目录里通常没有什么运行时数据保留即可占不了多少空间。另外一些部署方式会另外下载模型文件比如 embedding 模型或者 reranker 模型这些在 RAGFlow 的models目录里有存储位置。某些版本的官方部署脚本会在宿主机上挂载模型目录模型文件动辄 2-5 G删不删要权衡。你只需要部署时如果不用 rerank 模型可以只保留 embedding 模型目录能省不少。5.2 清理 Docker 构建缓存的隐藏大坑还有一个容易被忽略的点是 BUILD 缓存。如果你当时是直接拉取官方镜像部署那构建缓存基本没有。但如果你玩过自行构建、改代码、重新docker compose build那缓存就会越积越大。查看构建缓存大小docker system df如果 Build Cache 那一栏显示几 G可以执行docker builder prune清理掉闲置的构建缓存。如果想一次性把缓存清干净加-a参数。这一步跟 RAGFlow 本身没有直接关系但它会释放可观的磁盘空间对当前“空间不够”的场景帮助很大。这里做个对比总结占用来源清理命令风险等级空间释放量运行容器docker compose down低忽略不计悬空/无用镜像docker image prune低5-15 G构建缓存docker builder prune低1-5 G数据卷docker volume rm高数据永久丢10-30 G源码目录rm -rf /root/ragflow中看需求0.5-5 G6. 删除后的复检技巧与再部署建议6.1 验证磁盘空间是否真正释放删除完成之后不要急着结束跑一遍复检确认空间真的腾出来了。df -h再看 Docker 的占用docker system df如果已经清理干净Images、Containers、Local Volumes 的体积应该明显降下来。还有一个有意思的检查方法docker ps -a docker images docker volume ls逐项确认没有 RAGFlow 相关的残留。如果还有脏数据就用文中对应的命令再补一刀。我在一次清理中发现容器删了、镜像删了、卷也删了但磁盘占用还是很高用ncdu一查/var/lib/docker/tmp里有几个 G 的临时文件是之前构建镜像中断留下的。这种残留一般用docker system prune清掉。所以复检时如果发现空间释放不理想先看ncdu /var/lib/docker定位具体目录。6.2 如果还要重新部署保留数据的优雅方案万一你删除 RAGFlow 只是暂时性的后续还要部署我不建议把所有卷都删掉。比较优雅的方案是只停容器删容器和镜像保留卷。重新部署时在docker-compose.yml里声明外部卷挂载到原来的卷名。这样重新docker compose up -d后知识库数据都能无缝恢复。具体操作就是在 compose 文件的卷定义部分加上external: true并指定数据卷名称例如volumes: ragflow_mysql_data: external: true name: ragflow_mysql_data这样容器重建但旧数据还在。不过要注意如果把卷误删了那数据就找不回来了。如果环境里有一些重要数据建议先在卷中打一个 docker 快照用docker run --rm -v 卷名:/data -v $(pwd):/backup alpine tar czf /backup/volume-backup.tar.gz /data把数据备份出来总比删除后追悔莫及强。6.3 防止空间再次告罄的日常维护建议经历过一次磁盘告警之后我现在对服务器的空间管理比过去上心得多。这里分享几个我一直在用的维护习惯供参考Linux 平台对 Docker 的默认存储布局是大家熟悉的 overlay2 存储驱动数据都在/var/lib/docker下面。如果你经常遇到空间不够的问题最好给/var/lib/docker单独挂一个大容量分区或者把它用软链迁到大磁盘上去。生产环境建议直接把 Docker 数据目录单独放到数据盘上和系统盘隔离开系统盘满了Docker 再乱也不会把机器搞宕机。另外给容器日志加上轮转也是一个很容易被忽略的操作。像我部署 RAGFlow 的早期版本控制台日志全打到 stderr 里Docker 默认不给它轮转日志文件疯狂膨胀几十 G 的日志就这么攒出来的。建议在/etc/docker/daemon.json里配置日志限制{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }配置完重启 Docker 生效。新启动的容器就会自动限制日志大小避免系统盘被日志撑爆。已有的容器需要重建才生效旧日志还是需要手动清。最后养成定期清理的习惯。我一般一个月跑一次docker system prune -f docker image prune -f docker builder prune -f数据卷的清理则根据实际项目需求来不轻易加--volumes。这是我长期的运维习惯也算是被磁盘告警打了几次才学乖的。7. 常见问题速查表7.1 常见报错与排查思路问题现象可能原因解决办法docker compose down报错找不到 compose 文件当前目录不是 RAGFlow 源码目录先cd到有docker-compose.yml的目录再执行或者用docker ps --format ...找容器名手动删删除镜像报image is being used by container有容器还在引用该镜像先删容器再删镜像优先执行docker compose down删除卷报volume is in use卷仍被某个容器挂载可能容器为停止状态先执行docker rm删除相关容器再删卷停止状态的容器也占着卷引用磁盘释放不明显数据卷未删除构建缓存还残留日志文件还在用docker system df -v和ncdu定位针对性清理重新部署后数据不在数据卷被删或者挂载名不对检查 compose 文件的卷声明确保 external 卷名和原卷名一致7.2 我踩过的坑先说一个真实翻车案例。某次我在一台测试机上部署 RAGFlow 做评估跑了一些文档解析任务然后临时需要腾空间部署别的服务。当时我想着反正测试环境直接一条docker compose down -v全部清掉。结果过了两周甲方的人说测试报告里需要对着之前那份知识库跑一遍评测集问我能不能把环境恢复。我打开终端服务器上什么都没有了——容器、镜像、卷全清干净连源码目录都删了。最后我只能从零开始重新部署 RAGFlow重新灌数据重新跑测试。那次之后我养成了两个习惯第一删除前先列清单写清楚要删什么、保留什么。哪怕只是测试环境也要走一遍“确认数据可以丢”的流程不图一时手快。第二像 RAGFlow、知识库这类有业务含义的数据删之前一定先做一个备份脚本。实际上 RAGFlow 元数据在 MySQL 里源文件在 MinIO 里索引在 ES 里三者分离备份和恢复都有各自的链路单独备份 MySQL 并不能还原完整知识库。所以现在我会直接用docker run把整个卷目录打包存到别的地方统一动作不再按组件拆开备份。还有一个细节如果你用了较新的 RAGFlow 版本官方有提供一些基于 Web 界面的系统设置导出和重导功能但底层卷数据导出仍然是更根本的兜底方案。这一步别省。个人经验上我倾向于把“清理”这件小事也当成一个正式的运维动作来对待而不是临时几行命令应付。先设计清楚方案再动手这样后续出现任何需求变化都还有退路。