阿里云服务器系统盘满了，别慌，先这样排查最省事

很多人第一次遇到阿里云服务器系统盘满了，第一反应都是“赶紧扩容”。但说实话，扩容往往不是第一步，甚至有时候不是最优解。系统盘爆满背后，常见原因并不是业务真的把磁盘吃光了，而是日志失控、缓存堆积、Docker镜像残留、数据库临时文件暴涨，或者运维习惯不到位。

所以这篇文章不讲空话，重点讲一个更实用的思路：当阿里云服务器系统盘满了时，应该怎么判断、怎么止血、怎么避免下次再踩坑。

先搞清楚：系统盘满了，影响到底有多大

系统盘不是普通存储盘，它装着操作系统、软件环境、运行日志、临时文件，很多服务默认也往这里写数据。一旦系统盘接近100%，最直接的后果通常不是“机器立刻关机”，而是服务开始变得诡异：

• 网站突然变慢，甚至 502、504
• 数据库无法写入，新订单、新数据提交失败
• SSH还能连上，但执行命令明显卡顿
• 日志继续写不进去，排障反而更困难
• 自动更新、备份、发布任务全部异常

有些业务就是这样被拖垮的：不是CPU不够，不是内存不够，而是磁盘写满后整个系统进入“半瘫痪”状态。

别急着扩容，先做这3步判断

1. 先看是不是真的系统盘满了

有时候你看到控制台报警，就以为整台机器没空间了，其实可能只是某个分区打满。先确认磁盘使用情况，再决定动作。重点看根目录对应分区、/var、/tmp、/home这些常见高占用路径。

如果确定是根分区接近或达到100%，那就说明这次问题确实属于阿里云服务器系统盘满了。

2. 再看是“突然满”还是“慢慢满”

这一步非常关键。

• 突然满：通常是日志异常刷爆、程序死循环写文件、被攻击后产生大量垃圾文件、数据库临时文件瞬间膨胀
• 慢慢满：通常是历史日志没清、备份一直放系统盘、Docker镜像层层累积、开发包和缓存长时间不清理

如果是突然满，优先止血；如果是慢慢满，优先找长期结构性问题。

3. 最后看“谁”在吃空间

不要凭感觉删文件。很多人一着急，直接删数据库目录或者应用目录，结果空间没腾出来，服务还先挂了。正确做法是先定位大目录，再定位大文件，确认哪些是可以清理的，哪些必须迁移。

最常见的5类元凶

1. 日志文件失控

这是最常见的一类。Nginx、Java应用、Python服务、消息队列、系统日志，只要没做轮转，几天就可能膨胀到几十GB。尤其是报错频繁时，一个异常栈反复刷，系统盘很快被打爆。

很多团队以为“日志只是文本，不占多少空间”，实际上线上最容易失控的就是文本。

2. Docker镜像和容器残留

如果你的服务跑在Docker里，系统盘满的概率会更高。因为镜像层、容器日志、未使用卷、构建缓存，默认都可能堆在系统盘。业务迭代越频繁，残留越多。

一个常见现象是：明明项目代码没多大，但系统盘占用越来越高，最后发现是历史镜像一直没清。

3. 数据库或中间件把数据写到了系统盘

比如 MySQL 临时文件、Redis持久化文件、Elasticsearch索引、消息队列数据目录，如果部署时没单独规划数据盘，就容易把系统盘吃满。前期数据少问题不明显，业务一增长，磁盘压力马上暴露。

4. 备份文件放错地方

这也是中小团队常见问题。为了图省事，定时脚本每天把数据库备份到/root或者/var/backups，备份是做了，但从来没人清理。一个库几百MB不觉得大，连续存3个月就很可观了。

5. 临时文件和缓存长期无人处理

应用缓存、系统缓存、安装包、升级残留、/tmp目录文件，这些单个看都不大，但叠加起来很可观。很多服务器不是被“大文件”撑满的，而是被一堆“没人管的小文件”慢慢挤爆的。

一个真实感很强的排查案例

之前有个做电商的小团队，晚上突然反馈网站下单失败。最开始他们怀疑是支付接口波动，后来发现管理后台也开始报错。再查服务器监控，CPU不高，内存也还行，但磁盘使用率已经99%。典型就是阿里云服务器系统盘满了。

继续往下排查，问题出在一个促销活动上线后，接口参数校验异常，Java程序持续打印错误日志。由于日志没有做按天切分和压缩，一个日志文件两天内冲到二十多GB。系统盘原本只剩十几GB空闲，直接被打穿。

他们一开始想立刻扩容，但扩容并不能解决“错误日志持续疯涨”的问题。后来采取的是分两步：

1. 先清理历史无用日志，临时释放空间，让服务恢复写入能力
2. 再修复程序报错逻辑，补上日志轮转和告警阈值

结果很明显：如果只扩容，不处理根因，新的空间还是会继续被吃掉；如果先止血再治本，问题才真正结束。

正确处理顺序，决定你会不会越弄越乱

第一步：先止血，恢复最基本可用性

当阿里云服务器系统盘满了，首要目标不是“立刻优化到完美”，而是先让系统恢复喘息空间。比如清掉明确无用的旧日志、无效缓存、过期备份、废弃镜像，让系统先腾出几GB空间。

这一步要强调一个原则：只删你确认安全的内容。不确定的文件先查用途，不要上来就大面积删除。

第二步：定位根因，不让空间再次被瞬间吃掉

止血只是临时措施。真正关键的是搞清楚空间为什么会满：是程序异常刷日志，还是数据目录放错盘，还是镜像管理混乱。找不到根因，今天清完，明天还会满。

第三步：决定是清理、迁移，还是扩容

这一步要看业务实际情况。

• 如果只是日志和缓存问题，优化清理策略通常就够了
• 如果业务数据确实增长了，应该把数据迁到独立数据盘
• 如果当前规格本来就偏小，扩容才是合理选择

也就是说，扩容不是不能做，而是应该在看清原因后做，而不是把它当万能解药。

从根上避免再次出现

给日志做轮转和保留策略

日志必须按天或按大小切分，保留周期要明确，过期自动压缩或删除。线上日志的价值在“可排障”，不是“永久堆积”。

数据盘和系统盘职责分离

系统盘尽量只放系统和程序环境，业务数据、数据库文件、上传文件、备份文件尽可能放数据盘。这样即使数据增长，也不会直接威胁系统稳定性。

把监控阈值提前

别等到100%才报警。磁盘使用率到了70%、80%、90%时就该分级提醒。这样你还有时间处理，而不是等服务异常后被动救火。

定期做“空间体检”

每月看一次大文件、大目录、备份保留、镜像残留情况，成本不高，但很有效。很多故障本来都能在例行检查中提前发现。

最后说句最实在的话

阿里云服务器系统盘满了，表面看是空间问题，本质上往往是运维管理问题。真正成熟的处理方式，不是每次满了就加盘，而是形成一套习惯：先判断、再止血、后追根因，最后把日志、数据、备份、监控都规范起来。

服务器稳定这件事，很多时候拼的不是多高深的技术，而是谁先把这些基础细节做扎实。系统盘满一次，是事故；如果同样的问题反复出现，那就是流程漏洞了。

所以遇到这种情况别慌。先把问题看透，再动手处理，你会发现大多数“磁盘爆满”的故障，其实都能比较平稳地解决。