虚拟机磁盘空间突然暴增，绝大多数情况下是日志文件、快照文件、临时文件或数据库残留数据在后台持续写入造成的，而不是业务数据真的在短时间内增长了那么多。搞清楚这一点，你才能对症下药，避免被虚假的容量告警吓到。
先看日志：最容易忽略的隐形空间杀手
系统日志和应用程序日志是虚拟机磁盘膨胀的头号嫌疑犯。 尤其是运行了较长时间的Windows Server或Linux节点，日志文件的增长速度远超你的直观感受。
- Windows事件日志：System、Application、Security日志默认上限通常是20MB，但某些异常报错（如磁盘坏道重试、服务反复重启）会让日志在几小时内写满数十GB，且旧日志不会自动清除。
- Linux journald日志：systemd-journald默认只限制总容量的10%（通常足够），但如果你手动改过RateLimitIntervalSec或关闭了限额，日志文件会无限制增长。
- 应用日志：Nginx、Tomcat、MySQL的error.log和slow.log，如果没有配置logrotate轮转策略，单个日志文件轻松突破50GB，且删除后空间不一定立即释放（因为进程仍持有文件句柄）。
排查动作：登录虚拟机，执行df -h查看分区使用率，再用du -sh /var/log/按目录排序，找准大文件，Windows上可以用TreeSize或WizTree扫描C盘，注意先看C:WindowsLogsCBS（组件安装日志）和C:inetpublogsLogFiles（IIS日志）。
快照与备份残留：你以为删了，其实没删
快照文件（.vmdk或.qcow2）是虚拟机磁盘空间暴增的经典元凶，尤其是做虚拟化运维的同学。 很多人创建快照做变更前备份，但变更完成后忘了通过管理平台“删除快照”，结果快照文件越积越多。
行业共识认为：快照的本质是记录磁盘的增量变化，每次写入都会让快照文件变大，而且删除快照时需要做数据合并，期间还会额外占用临时空间，如果你看到虚拟机的磁盘文件大小远大于实际使用量，打开数据存储浏览器检查是否有大量-delta.vmdk或-snapshot文件。
- VMware场景：右键虚拟机 → 快照管理器，确认是否有多余快照，点击“删除全部快照”触发合并。
- Hyper-V场景：检查.avhdx检查点文件，尤其注意“标准检查点”会在底层创建一个完整的差异磁盘。
注意：删除快照后，虚拟机所在的数据存储可能会在短时间内出现空间不降反升的情况，因为合并过程需要额外空间暂存数据，建议在存储剩余空间充裕时操作，避免合并中断。
临时文件与缓存：系统自己“膨胀”了
虚拟机的临时目录和缓存目录往往被忽略，但它们确实是磁盘空间突然吃紧的直接原因。 尤其是安装了数据库、容器引擎或开发编译工具的虚机，临时文件的增长速度惊人。
- Windows系统：
C:WindowsTemp、C:Users用户名AppDataLocalTemp，以及Windows Update的下载缓存C:WindowsSoftwareDistributionDownload，这些目录里的文件常被程序意外锁定而无法自动清理，长期积累可达几十GB。 - Linux系统：
/tmp目录通常用tmpfs（内存盘），重启即清空，但/var/tmp是持久化的，Docker的/var/lib/docker/containers下的-json.log容器日志文件会无限增长，默认不轮转，直至占满磁盘。 - 数据库缓存：MySQL的binlog、InnoDB redo log，PostgreSQL的pg_wal目录，它们会持续写入，且不会因为“删除了旧数据”而自动缩小文件大小。
实操清理：
- Windows：运行
cleanmgr，勾选“临时文件”“Windows更新清理”，点确定；或用DISM /Online /Cleanup-Image /StartComponentCleanup清理WinSxS组件库。 - Linux：清理Docker日志用
echo '{"log-opts":{"max-size":"10m","max-file":"3"}}'配置daemon.json并重启Docker服务；清理pg_wal用checkpoint后设置wal_keep_size参数。
磁盘格式与扩容陷阱：一个疏忽让空间“凭空消失”
很多运维人员遇到过这种情况：虚拟机里的系统报告磁盘快满了，但在管理平台上看虚拟磁盘文件并没有那么大。 这往往涉及磁盘格式的动态增长和文件系统层面的预留空间。
- Thin Provisioning（精简置备）：VMware或KVM的虚拟磁盘初始很小，但写入多少就占多少，如果你在虚拟机里执行了大规模删除（比如清空一个大目录），宿主层面并不会自动回收这些空间，需要运行
fstrim -av（Linux）或在Windows中执行“优化驱动器”里的“Trim”操作，并开启存储层面的自动回收功能。 - 文件系统元数据开销：ext4默认预留5%的块给root用户，如果你把磁盘用满到95%就会报警，实际可用容量比标称值更少，XFS则没有预留，但碎片化程度较高。
- swap和休眠文件：Windows的
pagefile.sys（虚拟内存）和hiberfil.sys（休眠文件）加起来常占物理内存的1.5~2倍，如果你的物理内存是64G，这两个文件可能占用100G磁盘空间，建议将虚拟内存固定大小，或用命令powercfg /h off关闭休眠功能。
扩容建议：如果确实需要扩大磁盘空间，不要直接在管理平台改大虚拟磁盘后就完事，Windows要进“磁盘管理”扩展分区，Linux要操作fdisk或growpart扩容分区，再用resize2fs或xfs_growfs刷新文件系统尺寸，步骤不完整的话，磁盘大了但系统里看不到，反而容易误以为空间没变。
如何准确诊断：两个命令看穿真相
与其靠猜，不如直接用系统自带工具验证空间去向。 总结一套可复用的排查顺序，按权重从高到低执行。
- 先用
df -h看分区整体占用，确认是不是真的“满了”。 - 再用
lsof +L1列出被删除但仍被进程占用的文件，这种文件在df里看不到，但会持续占空间，杀掉对应进程即可释放。 - 然后用
du -x –max-depth=1 /从根目录逐层筛出大目录，找到具体是哪个路径在涨。 - 最后用
iostat -dx 1观察磁盘写吞吐，配合top或pidstat定位是哪个进程在疯狂写盘。
以一台突然告警的CentOS虚拟机为例：先df -h看到已用92%，第二步du -sh /var/log/发现/var/log/messages高达30G，第三步tail -f /var/log/messages发现某Java应用疯狂刷SocketException，那问题就不在磁盘本身，而在于修复应用报错切断日志写入源，再cat /dev/null > /var/log/messages清空文件。这只是其中一个典型案例，实际排查逻辑完全可复制。
虚拟机磁盘空间满了怎么办：紧急救援三步法
如果你已经连不上虚拟机,或者清理后空间仍然耗尽，按下面顺序操作。
- 第一步：尝试用管理平台挂载一个临时救援盘（如VMware的“添加硬盘”），将新盘挂载到虚机内，把关键数据复制出来。
- 第二步：通过Web控制台或VNC进入单用户模式/恢复模式，清理日志和临时文件，重启验证。
- 第三步：如果虚机本身已经无法启动，且快照删除失败，唯一的办法是克隆虚拟磁盘到新数据存储，再创建新虚机挂载该磁盘，这个过程要预留足够的宿主空间。
别急着扩容。 扩容只能临时缓解，根因不除，空间很快会再次被填满，微软和VMware的官方文档都指出，日志清理和监控配置需要一并调整。
Q&A：关于虚拟机磁盘空间暴增的常见疑问
为什么我删除了虚拟机里的文件，宿主机的空间却没有变少？
精简置备的虚拟磁盘虽然删除了文件,但存储层面不知道这些块已不再使用，你需要运行fstrim或在Windows里执行“优化驱动器”的Trim操作，宿主机才能回收空间，如果你的文件系统是旧版ext3，不支持trim命令，建议格式化时改用ext4或XFS。
虚拟机磁盘空间不足如何扩容，会不会导致数据丢失？
扩容的流程是：在管理平台把虚拟磁盘调大 → 在虚机内执行分区扩容 → 刷新文件系统。分区扩容的步骤有风险，操作前必须做快照或备份。 正确执行的情况下不会丢数据，但如果你用的是LVM逻辑卷，需要先lvextend扩展卷组，再resize2fs调整文件系统，顺序不能反。
快照文件出现后，磁盘空间一直在涨，正常吗？
快照的机制决定了它只增不减。每次有新的数据写入，原数据就会被复制到快照文件中永久保留，所以虚机运行越久，快照膨胀越大，这是设计使然，不算故障，但必须尽快完成合并，如果删除快照时提示空间不足，优先清理宿主机其他区域的日志或临时文件，为合并腾出临时空间。
本质结论：虚拟机磁盘空间暴增不是随机事件，背后一定有持续写入的进程。 按“查日志→查快照→查临时文件→查数据库残留”的顺序排查，十分钟内就能定位根因，把监控和日志轮转机制配置好，这类告警才能真正消失。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/733316.html
