阿里云服务器查看磁盘的正确方法与排查实战指南

很多人第一次接手云主机时，最常见的焦虑不是CPU跑满，也不是带宽告警，而是磁盘空间突然变少。尤其在业务上线一段时间后，日志、缓存、备份、临时文件会悄悄堆积，如果不能及时定位，轻则影响部署，重则导致服务异常。对运维人员和开发者来说，学会阿里云服务器查看磁盘，不是简单看一个“剩余容量”数字，而是要建立一套从控制台到系统内部、从现象到根因的排查思路。

这篇文章就围绕“阿里云服务器查看磁盘”展开，讲清楚怎么看、看什么、为什么看，以及磁盘异常时如何快速处理。

先搞清楚：你要看的到底是哪一层磁盘

很多人一提到阿里云服务器查看磁盘，第一反应就是登录控制台看云盘大小。这个动作没错，但它只能回答“分配了多少存储”，并不能完全说明“系统现在为什么没空间”。

通常要分成三层来看：

• 云平台层：实例挂载了哪些云盘，容量多大，是否扩容过。
• 操作系统层：系统识别到了哪些磁盘、分区和挂载点。
• 文件数据层：到底是哪个目录、哪个文件把空间占满了。

只有把这三层串起来，阿里云服务器查看磁盘才算真正看明白。

第一步：在阿里云控制台确认云盘信息

进入ECS实例详情页后，先看实例挂载的系统盘和数据盘。这里重点关注三件事：

1. 当前磁盘总容量是多少。
2. 是否存在单独挂载的数据盘。
3. 最近是否做过扩容，但系统里还没生效。

这一步的意义在于排除“认知误差”。比如控制台显示数据盘已经从100GB扩容到200GB，但服务器里依旧显示100GB，这往往不是扩容失败，而是分区或文件系统没有继续扩展。

也就是说，阿里云服务器查看磁盘时，控制台只能看到资源配置，不能替代系统排查。

第二步：登录服务器查看磁盘与分区

进入Linux服务器后，最常用的几个命令分别是：

• df -h：看各挂载点的已用空间和剩余空间。
• lsblk：看磁盘、分区、挂载关系。
• fdisk -l：看磁盘分区详情。
• du -sh *：看目录占用大小。

其中，df -h适合先总览，快速判断是根目录满了，还是某块数据盘满了。比如你会看到：

• / 快满：通常是系统盘压力大，常见于日志、容器镜像、临时文件堆积。
• /data 快满：通常是业务文件、数据库或上传内容增长过快。
• /var 所在分区满：多半和日志、缓存、包管理文件有关。

而lsblk的价值在于帮你确认：控制台挂了盘，系统是否真的识别到了；系统识别到了，是否已经分区；分区之后，是否已经挂载。

第三步：不要只看“磁盘满了”，要看“谁占满了”

这也是很多人做阿里云服务器查看磁盘时最容易忽略的一步。磁盘使用率高只是结果，真正有价值的是找到来源。

建议从大目录逐层往下查：

先看根目录下一级目录大小，再继续进入体积异常的目录深挖。常见的高占用区域包括：

• /var/log：服务日志、系统日志持续增长。
• /tmp：临时文件未清理。
• /home：用户目录堆积历史文件。
• /var/lib/docker：镜像、容器层、卷数据过大。
• /www 或业务目录：上传文件、备份包、导出文件累积。

如果只会看df，不会看du，就会停留在“知道满了，但不知道怎么处理”的阶段。真正有效的阿里云服务器查看磁盘，一定要落到目录和文件级别。

一个典型案例：明明扩容了，为什么空间还是不够

某电商项目在活动前把阿里云ECS数据盘从50GB扩到150GB，但开发登录服务器后发现业务目录还是提示空间不足，于是怀疑扩容没有成功。

后来排查发现：

• 阿里云控制台中，数据盘容量已经变成150GB。
• 系统通过lsblk也看到了更大的磁盘。
• 但原有分区大小没有同步扩展，文件系统仍然只用了50GB。

问题不在阿里云，而在于扩容后没有继续扩展分区和文件系统。这种情况非常常见。很多人完成控制台操作后就以为结束了，实际上系统层还差最后一步。

这个案例说明，阿里云服务器查看磁盘不能只盯着“总容量”，还要看容量是否真正被挂载点使用起来。

另一个高频案例：系统盘突然爆满，罪魁祸首是日志

还有一类问题更隐蔽。某接口服务运行半年一直正常，某天突然无法发布新版本。查看后发现系统盘使用率达到98%。控制台看起来一切正常，没有异常扩容，也不是磁盘损坏。

继续深入后发现，应用日志按天切分，但没有清理策略，单个日志目录累积到几十GB。由于日志写在系统盘，最终把根分区挤满。

这类场景很有代表性。因为很多团队在做阿里云服务器查看磁盘时，只在“出问题以后”才去查，而不是提前建立基线：

• 日志是否轮转。
• 备份是否自动清理。
• 临时文件是否定期删除。
• 容器镜像是否长期不清。

如果没有这些治理动作，再大的磁盘也可能被慢慢吃光。

如何提高查看效率：建立固定排查顺序

如果你不想每次都临时翻命令，建议把阿里云服务器查看磁盘固化成一个简单流程：

1. 先看阿里云控制台，确认云盘容量和挂载情况。
2. 登录系统执行df -h，判断是哪个挂载点告急。
3. 执行lsblk，确认磁盘、分区、挂载关系是否正常。
4. 对异常挂载点执行du排查，找到具体目录。
5. 定位后区分是临时增长、持续增长，还是扩容未生效。

这个顺序的好处是：不会一上来就在文件夹里盲找，也不会只看控制台就误判问题已经解决。

阿里云服务器查看磁盘时，最容易踩的几个坑

• 把内存问题当成磁盘问题：有时服务报错是缓存或交换分区异常，不一定是磁盘空间本身不足。
• 只看系统盘，不看数据盘：业务数据常常在单独挂载目录里。
• 扩容后不扩文件系统：这是最常见的“明明加了盘却没变大”。
• 删了文件却没释放空间：某些进程仍占用被删除文件，需要重启对应服务才会真正释放。
• 忽略容器环境：如果跑了Docker，真正变大的可能不是业务目录，而是镜像层和容器日志。

这些坑本质上都说明一件事：阿里云服务器查看磁盘不是看一个命令结果，而是理解磁盘使用的完整链路。

日常运维建议：别等磁盘报警才处理

最稳妥的做法，是把磁盘空间纳入日常巡检。对于中小团队，至少应做到：

• 定期检查系统盘和数据盘使用率。
• 对日志、备份、导出文件设置保留周期。
• 重要目录单独挂载，避免和系统盘混用。
• 业务增长明显时，提前评估扩容，而不是等到写满。
• 在监控中设置80%、90%两级告警。

这样做的价值，不只是避免磁盘爆满，更是让问题在影响业务前被发现。

结语

阿里云服务器查看磁盘，表面上是一个很基础的运维动作，实际上它考验的是排查方法是否系统。真正高效的做法，不是遇到空间不足才临时查，而是从控制台、系统分区、目录文件三个层面同时建立认知。

当你学会先看资源配置，再看挂载结构，最后定位到具体目录和文件，磁盘问题就不再是“玄学”。无论是扩容未生效、日志失控，还是业务文件暴涨，都能更快找到原因并处理。对任何线上服务器来说，这都是一项值得尽早掌握的基本功。