本文由『 云老大 飞弟：@yunlaoda360 / YunLaoDa-云服务器•运维部门•撰写』如需转载请注明！

阿里云ECS磁盘空间满了处理教程：从诊断到扩容的一线经验

ECS 实例突然写入失败、网站报 503 或数据库连接不上，运维群里最常跳出的截图就是 df -h 里那行触目惊心的 Use% 100%。阿里云的云盘扩容不算复杂，但真正让业务停摆的，往往不是扩容本身有多难，而是事前没做分层监控、事后清理时又不小心踩了 inode 耗尽或文件句柄占用的坑。这篇教程不会把 100 篇文档重复一遍，而是直接聚焦三个关键动作：诊断真实占用源、安全清理大文件，以及在线扩容到文件系统生效的全链路。

如何诊断ECS磁盘空间使用情况

磁盘满是一个结果，成因却可能在日志、业务数据、系统缓存之间任意组合。实际处理时，先花几分钟把占用水龙头摸清，比上来就 rm 要安全得多。

为什么 df -h 显示满了，但 du 查不出哪个目录占用高？

这是很多人遇到的第一个困惑。df 看的是文件系统层面的使用量，而 du 统计的是目录中可见文件的累计大小。如果二者差额很大，几乎可以断定存在已被删除但仍在被进程占用的文件。典型场景是应用日志被 rm 删除，但 tomcat 或 nginx 进程未重启，文件句柄没释放，内核就会把这些块继续算在磁盘占用里。应急命令通常用 lsof +L1 | grep deleted 找出这些“幽灵文件”，然后重启对应的进程释放空间。数据库意外撑满 /tmp 时也常出现这种情况，重启是最快的解法。

怎样精准定位占用最大的目录而不被缓存干扰？

du -sh /* | sort -rh 这条命令是实战里出镜率最高的诊断手段，它从根目录逐层向下展开，比遍历全盘快几个数量级。需要注意的是，/proc、/sys 等虚拟文件系统不要计算在内，另外 /var/log 和 /var/lib/docker 是绝大多数阿里云 ECS 容量告警的源头。如果是 Docker 环境，docker system df 能快速判断是镜像、容器还是卷占了空间。查到具体目录后，再考虑是清理还是转移。有个容易忽略的点是 inode 使用率，df -i 看到的是这个维度，大量小文件（比如邮件队列、session 文件、Node.js 的 node_modules 残留）会让磁盘明明还有空闲却无法新建文件，清理时得按照文件数量而非容量来规划策略。

Linux大文件查找与清理方法

磁盘空间告急时，最重要的不是急着敲 rm，而是先定位到真正占坑的文件。运维中超过70%的磁盘满告警，根源是日志文件无序增长和各类备份包堆积，真正系统文件膨胀反倒少见。下面三个步骤，能在不重启业务的前提下完成空间回收，且避免“删了文件却不释放空间”这类典型踩坑。

用find命令查找超过1GB的文件

先把大块头找出来。命令 find / -type f -size +1G -exec ls -lh {} \; 可以直接列出所有超过1GB的文件，但如果生产磁盘I/O吃紧，建议从 /var/log、/home、/tmp 这些高频区局部扫描。曾经有一个在线服务的扩容案例，运维全局扫描发现大量日志，但实际上 Docker overlay2 目录偷偷攒了37GB废弃镜像层，最终靠局部 du -sh /var/lib/docker/* 才抓到真凶。另外，inode耗尽也会表现为“空间未满却写不进去”，此时需要 find -type f | wc -l 统计大量小文件的目录，而非只看磁盘容量。

清理无用的日志和备份文件

日志是吞噬空间的惯犯。一个日均10万PV的Nginx站点，access.log 一个月轻松积累20GB以上。安全做法不是直接删除，而是配置 logrotate 按天压缩存档，并保留最近7天数据，既能合规又能控制体积。对于 mysqldump 这类定时备份生成的SQL文件，应该建立“本地留存3天+远端归档”的机制，比如同步到阿里云OSS，避免ECS本地沦为备份仓库。容易被忽略的是 /var/log/journal 下 systemd 的二进制日志，其默认上限可达磁盘的10%，建议在 /etc/systemd/journald.conf 中把 SystemMaxUse 设为1G左右，别让它无限膨胀。

删除或压缩大文件

对大文件下刀，最容易栽的坑就是 rm 被进程占用而无法释放空间。先 lsof | grep deleted 看一眼，把持有句柄的进程重启才是正道。对于不再频繁读写的静态大文件，压缩比往往能超过60%，tar -czvf archive.tar.gz large_dir 之后再删除源文件，兼容性与成本兼得。如果磁盘已经满到 df -h 显示100%且连 ls 都报错，可以应急清空一个确定的日志：> /var/log/syslog，抢回几百兆空间后继续操作。这一步不止是回收空间，也是在为后续云盘扩容争取操作余地。

系统缓存与临时文件清理

不少运维第一次排查磁盘满问题时，习惯直接从根目录 du -sh * 逐层下钻，却忽略了几个“小而分散”的缓存与临时目录。这些目录单次产出的文件都不大，但长期累积后往往能吃掉 5 GB 甚至 10 GB 以上的空间，对于 40 GB 规格的云盘来说已经足够触发告警。遵循“优先清理可安全删除数据”的原则，先处理这几处风险极低、效果立竿见影的位置。

清理 yum/apt 缓存

CentOS/RHEL 系的 yum 和 Debian/Ubuntu 系的 apt 在安装、更新软件包时，会把下载的 rpm/deb 包缓存到本地。以一台运行了两年的 CentOS 7 为例，/var/cache/yum 下累积的缓存包经常超过 3 GB，而这些文件在系统正常运行时几乎没有保留价值。清理命令非常简单：yum clean all 或 apt-get clean。需要留意的是，如果还有未完成的系统更新，先让更新跑完再清理，避免缓存被重复下载。生产环境建议顺手执行 yum makecache 重建元数据缓存，这样后续 yum search 不会因缺少元数据而报错。

清理 /var/log 日志文件

/var/log 是磁盘满的高发区，大日志文件常见于未配置轮转的 nginx access.log、mysql slow log 以及 systemd journal。实际操作中，用 journalctl --disk-usage 查一下 journal 日志占用量，经常能发现它悄悄用掉了 2 GB～4 GB。可以用 journalctl --vacuum-size=200M 将其压缩到 200 MB。然后再看经典场景：一个 25 GB 的 messages 文件，直接用 > /var/log/messages 清空比 rm 更稳妥，因为几乎可以肯定 syslogd 正持有该文件的写入句柄。清理后务必检查业务的写日志进程是否正常，防止因清空日志导致应用异常退出，同时顺手配上 logrotate 规则，避免下周又被打满。

清理 /tmp 临时文件

/tmp 目录理论上应该存放生命周期很短的临时文件，但很多程序（尤其是编译安装的中间文件、会话缓存）会把数据长期遗留在这里。可以先用 find /tmp -type f -atime +7 找出 7 天未访问的文件，再按大小过滤出真正占空间的部分。对于运行时间超过半年的云服务器，/tmp 下残余的系统更新缓存、PHP session 文件、容器临时图层等，清出 1 GB～2 GB 并不罕见。清理时留意正在运行的服务是否依赖某些看似无用的临时文件，例如 MySQL 在 /tmp 可能保留 socket 文件或临时表数据。稳妥的做法是在业务低峰期清理，同时配合 lsof /tmp/ 检查是否仍有进程占用。

阿里云云盘扩容操作步骤

当文件清理无法满足增长需求时，就需要在云盘层面直接扩大底层存储。阿里云支持在线扩容，整个过程不会停机，但控制台按钮按下后只完成了一半工作——操作系统不会自动识别新增的物理空间。根据运维社区的长期实践，完整的扩容链路必须走完“控制台扩容→分区扩展→文件系统扩展”三步，缺一不可。

在控制台扩容云盘

登录ECS管理控制台，在“存储与快照”中找到目标云盘，选择“扩容”。这里有两处细节容易踩坑：一是扩容后的容量不能超过所选实例规格支持的上限，部分老旧规格仅支持2 TiB；二是如果云盘已挂载且实例为运行状态，扩容会自动触发在线操作，但某些早期版本的内核需要重启才能识别新大小，生产环境最好先在测试实例上演练。完成扩容后，控制台显示的目标容量即是物理极限，但df -h依旧停留在旧数值，此时必须进入系统进行分区层面的修正。

确认扩容后磁盘信息

登录ECS实例，先用lsblk查看块设备，确认对应云盘的整体大小已经增长。然后判断该盘的分区类型：对于使用了MBR分区的数据盘，如果扩容后超过2 TiB，需要先借助fdisk或parted将分区表转换为GPT，再使用growpart工具扩展分区（例如growpart /dev/vdb 1）。接着根据文件系统类型执行扩容——ext4用resize2fs，XFS用xfs_growfs /mount/point，最后df -h验证挂载点容量。整个过程只需数十秒，但大量案例显示，跳过“扩展分区”直接运行文件系统扩容命令，会导致数据不可读，必须回退重做。

注意事项与风险提示

最容易引发事故的不是技术复杂度，而是“扩容即生效”的错觉。阿里云控制台扩容按钮点击后，后台立即分配空间，但前端不主动提示后续命令，很多非专业运维因此遗漏扩展操作，直到磁盘再次填满才发现新空间未启用。建议企业将这三步命令脚本化并纳入运维手册。另外，如果在分区扩展时发生中断，可能导致分区表损坏，操作前务必对系统盘或数据盘创建快照。对于关键业务，配置云监控的磁盘使用率告警（如>80%触发）比事后扩容更有成本效率，若内部缺乏运维人力，评估服务商的一站式托管方案也是一种降低中断风险的务实选择。

扩容后的磁盘分区调整

在阿里云控制台完成云盘扩容后，有一个事实常被初次操作的用户忽略——此时登录服务器执行df -h，看到的可用空间不会发生任何变化。这不是扩容失败，而是操作系统层面的分区表和文件系统尚未被告知“磁盘边界已经外移”。从控制台的物理扩容到系统可用的这“最后一公里”，需要手动完成分区和文件系统的连续调整。

使用growpart扩展分区

growpart是这一链路的第一环，负责更新磁盘分区表，告诉操作系统某块盘的某个分区现在可以占用更大空间。这里有一个反复出现在运维事故中的坑：执行growpart时必须指定“分区号”而非“分区名”。也就是说，如果你要扩展的是/dev/vda1，命令应为growpart /dev/vda 1，而非growpart /dev/vda1。输错会导致“unexpected output”报错，而99%的首次扩容失败都卡在这一步。另外，CentOS 7/8的默认镜像未必自带该工具，若提示command not found，执行yum install -y cloud-utils-growpart即可，不必重新挂载或重启实例。

使用resize2fs扩展文件系统

分区边界扩展完成后，df -h看到的文件系统大小仍然保持原样。接下来要做的，是根据文件系统类型选择扩展命令。如果是ext4，使用resize2fs /dev/vda1；如果是xfs——也是阿里云CentOS 7默认的根分区格式——则应执行xfs_growfs /。一个关键判断依据是：xfs_growfs后跟的是挂载点而非设备名，这是两项操作在语法上最容易混淆的地方。在执行resize2fs之前，建议先跑一次e2fsck -f /dev/vda1对文件系统做强制检查，虽然会多花费十几秒，但能有效避免因元数据不一致导致的扩展失败。实测中，40GB扩至100GB的ext4系统盘，resize2fs耗时通常在30秒以内。

验证扩容结果

扩展完成后不要依赖单一命令确认结果。先执行lsblk查看块设备层级——它能直接反映云盘在操作系统层面的真实大小，不受文件系统影响。再执行df -h对比挂载点的容量，两者数值应对齐。如果lsblk已显示100GB而df -h仍为40GB，说明分区和文件系统扩展的某一环出了问题，需要回溯排查而非直接投入使用。

预防磁盘空间满的最佳实践

在处理过数十起阿里云ECS磁盘爆满的应急工单后，一个明显的规律浮现出来：绝大多数故障并非因为业务增长真的撑满初始配给的空间，而是缺乏一套前置的预防机制。修复后不补上运维的“短板”，扩容后的云盘很快会再次告急。

设置日志轮转策略

某外贸SaaS团队的一次夜间宕机，事后复盘发现根因只是一份持续写了3个月的Nginx access.log，体积达到47GB，直接撑爆了/var分区。这就是典型的日志失控。logrotate 是 Linux 下最通用的方案，但它的默认规则远不够用。我们建议针对/var/log下的业务日志单独增加配置：按“每天轮转+保留最近7份”的策略执行，同时对日志做压缩，这样能把历史日志占用的空间减少80%左右。对写入速率极快的应用，还可以用maxsize限制单文件大小，让轮转更频繁，避免单个文件失控。清理前务必确认日志有无合规或审计需求，必要时先同步至阿里云OSS再删除本地副本，做到可追溯又不占用系统盘。

定期监控磁盘使用率

单纯靠人盯盘，很难在空间被吞掉前及时反应。更务实的做法是把监控前置到ECSwarning线以内。在阿里云控制台的云监控服务中，可以为系统盘和数据盘分别设置使用率报警——我们一般推荐将阈值定在75%发出第一级告警，85%触发紧急通知。这样运维人员能在“接近满”而不是“已经满”的阶段介入。另外，结合ncdu或du -sh /* | sort -rh做一次磁盘快照的月度检查，也能尽早发现“悄悄长大”的/tmp、/.cache或某个docker的overlay2目录。某技术社区里流传过一条经验：让监控脚本每天邮件推送一次TOP5大目录，这个简单操作让很多团队把90%的潜在磁盘问题扼杀在萌芽期。

清理不用的Docker镜像和容器

在开发测试环境中，Docker残留是磁盘占用的隐形炸弹。一个跑了半年K8s的节点，/var/lib/docker下经常能捞出数十GB的无用镜像和已停止的容器快照。docker system prune -a能一键清除未运行的容器、悬空的镜像和构建缓存，但生产环境执行前必须确认业务进程不依赖这些中间层。更精细的做法是定期执行docker image prune --filter "until=72h"删除3天前创建的且未被任何容器使用的镜像。结合docker container prune，我们曾在一台入门级ECS上一次性释放出14GB空间，让原本即将变红的磁盘使用率直接回落到60%以下。