AWS返现 AWS亚马逊云清理磁盘空间技巧

亚马逊aws / 2026-04-17 17:09:30

话说你有没有过这种时刻——刚登录EC2实例，随手敲个 df -h，结果终端瞬间变“灵异现场”：/dev/xvda1 使用率赫然显示 98%？紧接着sudo tail -n 20 /var/log/syslog一瞅，日志文件比你去年写的年终总结还长；/var/cache/apt/archives/里躺着几十个没用过的.deb包，像被遗忘在抽屉深处的旧电影票；更绝的是，/usr/src/下居然堆着三套不同版本的Linux内核源码，而你连uname -r都懒得记……别慌，这不是系统中邪了，是AWS云上最朴实无华的生存日常。

AWS返现 先破个迷信：AWS的EBS卷不会自己“长胖”，它只是忠实地记录你每一次echo "hello" >> /tmp/bigfile.log，每一回apt update && apt upgrade留下的历史包，每一条被journalctl --vacuum-size=500M遗忘的日志碎片。磁盘爆满不是玄学，是可追溯、可干预、可预防的物理事实。

第一步：精准定位“空间刺客”

别急着删！先当侦探。执行这三行命令，顺序不能乱：

df -h                          # 看整体：哪个挂载点快撑爆了？
du -sh /* 2>/dev/null | sort -hr | head -10   # 看根目录下谁最占地方（忽略权限错误）
sudo du -sh /var/* 2>/dev/null | sort -hr | head -8  # 重点盯防/var——日志、缓存、数据库的重灾区

注意：du和df结果常有出入？正常！df读取的是文件系统元数据，du实际遍历文件大小——如果某进程删了大文件但没释放句柄（比如nginx还在往已rm的日志里写），df就看不到空闲，而du统计不到它。此时跑lsof +L1，就能揪出那些“已删除但未释放”的幽灵文件。

第二步：对症下药，逐个击破

① 日志炸弹——/var/log的定时炸弹
Ubuntu/Debian默认用rsyslog，Amazon Linux用journald。前者日志在/var/log/下按天轮转，后者全塞进二进制数据库。别手动rm -rf /var/log/*.log！风险极高。正确姿势：

rsyslog系：用sudo logrotate -f /etc/logrotate.conf强制轮转+压缩，再sudo find /var/log -name "*.log.*" -mtime +30 -delete清掉30天前的归档
journald系：先journalctl --disk-usage看占多少，再sudo journalctl --vacuum-time=2weeks只留两周，或--vacuum-size=200M硬性限额

② 缓存垃圾——/var/cache的沉默囤积者
APT/YUM缓存是典型“只进不出”。Ubuntu用户：sudo apt autoremove && sudo apt autoclean（前者删旧内核/依赖，后者清下载包）；Amazon Linux用户：sudo yum clean all && sudo yum autoremove。额外彩蛋：sudo apt install ncdu && ncdu /var/cache——交互式磁盘分析器，箭头键导航，d键删除，比rm直观十倍。

③ 内核残影——/lib/modules与/usr/src里的“前任们”
每次apt upgrade都可能装新内核，但旧内核不会自动卸载。查当前用的：uname -r；看所有已装：dpkg -l | grep linux-image（Ubuntu）或rpm -qa | grep kernel（AL2）。只留当前+一个备用，其余全删：sudo apt purge linux-image-5.4.0-100-generic（Ubuntu）或sudo yum remove kernel-4.14.252-195.483.amzn2.x86_64（AL2）。删完记得sudo update-grub（Ubuntu）或sudo dracut --force（AL2）更新启动项。

④ 临时文件——/tmp的合法“灰色地带”
AWS官方AMI通常配置systemd-tmpfiles自动清理/tmp，但若自定义过fstab挂载tmpfs，或应用写死路径到/tmp，就容易堆积。检查sudo systemctl status systemd-tmpfiles-clean.timer是否启用；手动清理：sudo find /tmp -type f -mtime +7 -delete 2>/dev/null（7天以上普通文件）。

第三步：建立防御体系，告别救火队员

靠手动清理是体力活，自动化才是王道。在/etc/cron.weekly/下建脚本aws-disk-clean（记得chmod +x）：

#!/bin/bash
# AWS磁盘健康巡检脚本
THRESHOLD=85
USAGE=$(df / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ $USAGE -gt $THRESHOLD ]; then
  echo "[WARN] Root disk usage: ${USAGE}%" | logger -t disk-clean
  journalctl --vacuum-size=100M
  apt autoremove -y && apt autoclean -y 2>/dev/null
  find /var/log -name "*.log.*" -mtime +14 -delete 2>/dev/null
  find /tmp -type f -mtime +3 -delete 2>/dev/null
fi

再加个“温柔提醒”：在/etc/profile.d/disk-alert.sh里写一行：df -h | grep '100%' && echo "⚠️ 磁盘告急！快跑 df -h 查看"，下次SSH登录就自动弹窗警告。

最后，说点掏心窝子的话

清理磁盘不是技术炫技，而是云上生存的基本素养。有人觉得“扩容EBS更省事”，没错，但100GB卷和500GB卷的备份时间、快照费用、IOPS成本，差的可不是一点半点。更关键的是——当你的CI/CD流水线因No space left on device中断，或者监控告警疯狂刷屏时，翻文档查命令的手速，远不如早先设好的cron脚本来得可靠。

所以，下次看到df -h里那抹刺眼的红色，请把它当成系统递来的便签条，上面写着：“嘿，朋友，该给这台EC2倒倒垃圾了。” 而你现在，已经知道怎么优雅地拎起垃圾桶，还顺手给它装了个自动感应盖。