云服务器磁盘满了怎么办？Docker日志、镜像和数据卷哪些能清理

网站还能打开，后台却上传不了图片；更新一个Docker应用，终端突然报出No space left on device。你搜索“Docker清理磁盘”，看到一串命令，又不敢按回车：数据库也在这台机器上，清完还在不在？

这个担心很实际。释放空间不难，难的是认清哪些文件能丢、哪些承载着业务。先确认写满的位置，再按对象清理。不要把整个Docker目录当成缓存，也不要把“未使用”直接理解成“没价值”。

本文面向使用Docker Engine的Linux云服务器，命令以常见Debian、Ubuntu等环境为例。检查步骤是只读操作；涉及删除、重建的地方会单独说明前提。这里没有拿你的服务器做实测，也不承诺一条命令适用所有部署方式。

第一步：确认满的是哪个磁盘，还是inode用完了

先看报错目录所在的文件系统

连接服务器后，先执行：

df -h
df -i

df -h看容量，重点是Avail、Use%和Mounted on；df -i看inode，重点是IFree和IUse%。inode可以理解为文件系统用来登记文件的资源：大量小文件也能把它耗尽，即使磁盘还剩不少GB。

不要只看第一行。系统盘、数据盘、临时文件系统分别有自己的容量。如果报错发生在/data，而数据盘挂载在那里，清理系统盘上的下载文件并不能解决它。也可以把真实报错目录作为参数，例如df -h /data，直接检查它所在的文件系统。

看到overlay也别把每一行相加，它们常指向同一个底层文件系统。若容量和inode都充足，继续查报错进程看到的挂载点、容器内路径、用户配额或临时文件系统，不要强行套用“清理大文件”方案。阿里云官方排查文档也将容量耗尽、inode耗尽和已删除文件仍被占用分开处理。

再找占用目录，不急着删除

下面命令适用于使用GNU工具的常见Linux系统，扫描会产生磁盘读取；繁忙机器先查已知目录，避免反复扫整盘：

sudo du -xhd1 /var
sudo du -xhd1 /var/log
docker info --format '{{.DockerRootDir}}'
docker system df -v

du显示目录占用；-x限制在同一文件系统，-d1只展开一层。假如/var下另挂了数据盘，这个参数会跳过该数据盘，必须单独检查它的挂载点。Docker数据目录也不一定是默认路径，先用docker info确认。

docker system df -v用于区分镜像、容器和数据卷等占用，不能把它当成包含所有宿主机日志和挂载目录的完整磁盘账单。RECLAIMABLE表示Docker判断可回收的空间，不代表你已经确认业务不需要。命令字段说明见Docker官方文档。

先确认资源类型，再找对应目录；两条分支都需要检查文件归属。

第二步：分清Docker占用，确定哪些内容可以处理

镜像和构建缓存：先留好回滚需要的版本

镜像是启动应用的基础，不是数据库备份。日常升级留下的旧镜像、反复构建留下的缓存，适合优先核查，但仍要确认能否重新获取，以及是否承担回滚用途。

对象	清理前要确认什么	删除后的影响
悬空镜像	没有容器引用，也不需要保留调试或恢复	后续需要时重新构建或获取
旧版本镜像	已有可用回滚方式，镜像仓库仍可访问	失去本机现成的旧版本
构建缓存	不需要保留离线构建资源	下次构建更慢，需重新下载依赖
停止的容器	可写层里没有唯一数据，配置已保存	容器本身及其可写层消失
数据卷或宿主机挂载目录	明确所属应用，备份可恢复，确认废弃	涉及数据库、上传文件等业务数据

对已确认不需要的悬空镜像，可以使用docker image prune；对已确认可重建的构建缓存，可以使用docker builder prune。这两条都会修改本机数据，不要当检查命令执行。保留交互确认，读清本机输出后再决定。

docker image prune -a范围更大，会处理没有任何现存容器引用的镜像。你准备留作回滚、但暂时没有创建容器的版本，也在这个范围内。镜像拉取本来就有困难时，先看Docker镜像拉取失败排查，别先删掉最后一个能启动的版本。这些清理范围以Docker官方说明为依据。

停止的容器：先检查数据有没有写在可写层

“Exited”只表示容器已停止。测试结束的容器和故障后停止的正式数据库，都会出现这个状态，处理方式却完全不同。

先看docker ps -a --size，再用docker inspect 容器名 --format '{{json .Mounts}}'核对挂载。这里的“容器名”要替换为真实名称。不要把完整inspect输出直接贴到公开论坛，它还包含其他配置；本例只选择挂载字段。

如果应用把上传文件写在容器内部，又没有挂载持久化存储，删除容器会丢失这部分数据。先转移并验证文件，再安排重建。不能因为容器已经停了，就批量清空停止容器。

数据卷和数据库：不靠目录名字判断能不能删

一个没有容器引用的数据卷，仍然能保存上次部署的数据库。重新创建应用、切换Compose项目名之后，旧卷暂时没有挂载，数据却依然有用。匿名卷名字难认，也不等于临时垃圾。

对每个准备处理的卷，先记录卷名、关联项目、应用内挂载路径、最后使用情况，再按数据库或应用自己的方式备份。数据库正在写入时，直接复制底层目录不能自动保证得到可恢复的备份。

同样，不要手工删除Docker管理目录里的层文件，也不要删除MySQL数据文件来腾空间。目录占用很大，只能证明它值得检查，不能证明它该被清理。备份对象和恢复验证可以对照云服务器快照与备份恢复指南。磁盘已经满时，不要把新备份再写进同一个满盘。

判断标准是数据是否还能恢复，而不是对象是否正在运行。

第三步：日志占满磁盘，要处理增长原因和轮转

先确认日志驱动及最近错误

查看目标容器的日志配置和最近输出：

docker inspect --format '{{json .HostConfig.LogConfig}}' 容器名
docker logs --since 10m --tail 100 容器名

把容器名替换成实际名称。不同日志驱动的读取能力不同；若命令提示不支持读取，就查对应日志后端。日志也会包含用户信息、请求内容或密钥，分享前要脱敏。

同一条连接失败每秒重复几次，和正常访问记录不断增长，是两类问题。前者要修复连接配置、失败重试或日志级别；只释放空间却不处理持续报错，很快还会写满。应用自己写入挂载目录的日志，则需要应用或系统的轮转机制，不能只修改Docker标准输出日志设置。

给Compose服务设置日志轮转

下面是合并到现有服务中的配置片段，不是完整部署文件。app要替换成已有服务名，并保留原有镜像、环境变量、端口和挂载配置：

services:
  app:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

这是一组示例值，用来说明如何限制单个容器的日志文件大小和保留数量。实际需要保留几天日志，应结合输出速度与排错需求确定。多容器各自计数，它也不是全机存储上限。Compose的logging配置入口允许按服务指定驱动及选项。

修改后先执行docker compose config --quiet检查配置。通过只表示配置能够解析，不代表日志已经开始轮转。现有容器不会因为修改了配置文件就自动采用新设置。 完成挂载和备份检查后，在维护窗口重建受影响的服务，再用inspect确认实际配置；单纯重启旧容器不能代替这一步。

Docker明确提醒，json-file日志文件由守护进程管理，外部直接操作会干扰日志系统。因此这里不提供直接删除或截断Docker日志文件的一键命令。日志巨大时，先保留必要故障证据，确认持久化数据和重建步骤，再通过容器生命周期处理旧日志。轮转选项和生效条件见官方文档。

如果你不依赖JSON日志文件采集，还可以评估local驱动，它默认具有轮转功能；已有日志采集系统时，应先确认兼容性再调整。Docker日志驱动建议

别把docker system prune当成日常急救按钮

默认的docker system prune会处理停止容器、未被容器使用的网络、悬空镜像和未使用构建缓存，默认不删除数据卷。加上-a会扩大镜像处理范围；当前官方文档中，--volumes涉及未使用的匿名卷。不同选项有不同边界，最终也要核对本机版本和确认提示。

“默认不删卷”并不等于“不会丢业务数据”：没有持久化的内容还在容器可写层里。带-f只是在跳过确认，不会替你判断数据是否重要。把这些选项拼成一条命令复制执行，省掉的恰好是最需要人工检查的部分。Docker system prune官方范围

这类批量命令更适合已梳理资源、可重建的开发环境，或有完整资源清单和恢复方案的维护任务。只有一台正式服务器、数据库挂载还没弄清楚的情况下，按对象处理更容易核对结果。

清理后没有恢复，接着检查这三件事

文件删了，空间却没回来

先对比同一个文件系统的df输出，不要拿另一个挂载点比较。如果文件已经删除但进程仍持有打开的文件句柄，空间不会立即释放。装有lsof的环境可用只读命令sudo lsof +L1查看这类文件。

确认所属进程后，按该服务支持的方式重新打开日志，或安排受控重启。不要看到一个进程号就强制结束数据库；也不要为了安装排查工具继续向已满磁盘写入大量软件包。

空间有了，网站还是报错

检查容器状态、近期日志以及数据库是否完成正常启动。网页首页打开，只能证明一次页面请求成功；还要验证原先失败的动作，例如上传测试文件、读取已有内容、提交一条可撤销的测试记录。

磁盘写满期间发生的失败任务不会都自动补跑。检查定时备份、消息队列和应用任务记录，先确认失败范围，再决定重试，避免重复提交订单或重复发送通知。测试结束后清理测试记录，并记下故障时间和处理对象。

空间很快又用完

隔一段时间对同一目录再次测量，判断是哪类文件持续增长。若日志爆发，先修复异常；若是备份层层累积，设置保留周期并确认异地副本；若是用户上传和数据库正常增长，再规划容量。

升级前要确认买到的是哪块盘、能否扩容现有磁盘，以及操作系统里的分区和文件系统还需哪些步骤。云盘容量增加不等于文件系统已经可用。实际操作按服务商和当前文件系统文档执行，不要拿别人的扩容命令直接套用。

什么时候该扩容，什么时候先清理

短时间堆积的旧构建缓存、可重新获取的文件，适合梳理后清理。正常业务数据已经占据大部分容量、清理完仍没有维护余量，就该安排扩容或迁移。维护余量还要容纳镜像更新、临时文件、数据库维护和恢复操作，不能只算今天的数据体积。

选择MatrixIDC云服务器时，可以先列出系统、应用镜像、数据库、上传文件和本机备份的占用，再查看当前产品与配置。对扩容方式、磁盘类型和备份条件有要求，购买前逐项确认。多买CPU和内存，不能直接解决磁盘容量不足。

对“Docker磁盘满了怎么处理”的直接回答是：先区分容量与inode，定位占用，再按日志、缓存、镜像和业务数据分别处理。保留回滚所需镜像，数据卷先确认归属和备份；处理后验证业务，并控制持续增长的来源。

常见问题：清理前最容易混淆的几个地方

删除镜像会删除数据库吗？

镜像和数据卷是不同对象。但这不意味着所有“Docker清理”命令都只删除镜像。先看实际命令操作的是镜像、容器还是卷，再检查数据库是否持久化，不能只凭命令里出现Docker就判断风险。

不运行的数据库容器，可以直接删除吗？

不能仅凭停止状态决定。先确认数据在卷、宿主机目录还是容器可写层，保存部署配置并验证备份。恢复时还需要正确的数据库版本、账号配置和应用连接信息。

设置了日志轮转，旧日志会马上变小吗？

修改配置文件本身不会让现有容器自动切换日志设置，也不会替你清掉已有的大文件。先确认配置应用到实际容器，再按受控维护流程处理旧容器；不要在业务运行中直接操作Docker管理的日志文件。

磁盘满了，重启服务器能解决吗？

重启不会让持久化业务数据消失。对于仍被进程打开的已删除文件，关闭相应句柄能释放空间；对于正常存在的日志、数据库和镜像，仍要找到占用原因。先诊断再安排重启，避免把可以处理的空间问题变成更多服务无法启动。

核对日期：2026年10月26日。命令与配置说明基于文中链接的官方文档；执行前请核对本机Docker版本、挂载方式和恢复条件。