问题来了：磁盘突然变红
前两天同事老李急匆匆跑过来，说监控报警，一台文件服务器的根分区使用率飙到了98%。我打开监控一看，确实，/dev/sda1 红得刺眼。这种事其实挺常见，尤其是一些老旧系统没做定期清理，日志、临时文件堆成山，一不留神就撑爆了。
但这次有点不一样，df 显示用了98%，可 du 一层层查下来，加起来还不到70%。这说明有文件被删除了，但进程还在占用，空间没释放。这种情况在运维圈里叫“幽灵占用”。
定位隐藏的占用者
先上命令：
lsof +L1 | grep deleted这条命令能列出所有被删除但仍被进程打开的文件。结果刷出一堆 access.log 的记录，来自 nginx。原来是上周日志轮转出了问题，旧文件删了但句柄没关。找到对应的 PID，重启服务后，空间立马释放了十几个G。
文件系统损坏怎么办
还有一次更惊险。一台 NAS 挂了，mount 不上去，报错 filesystem needs recovery。这种通常是因为非正常断电或强制拔盘导致元数据不一致。
这时候别慌，先试试 ext4 的修复工具：
e2fsck -f /dev/mapper/vg-nas-f 参数是强制检查，即使文件系统标记为 clean 也执行。运行后发现几十个 inode 错误，自动修复后重新挂载，数据基本都在。但要注意，e2fsck 期间不能挂载，得停业务。
RAID 阵列中的坏盘处理
如果底层是 RAID，比如 mdadm 软阵列，一块硬盘亮黄灯，别直接拔。先看状态：
mdadm --detail /dev/md0确认是 degraded 状态，然后把坏盘标记为 faulty：
mdadm /dev/md0 --fail /dev/sdb1等它彻底离线后再移除，换新盘，重新加入。重建过程会慢一点，但数据不会丢。
预防比修复更重要
很多问题其实是可以避免的。比如定期跑日志轮转，用 logrotate 配合 compress，一年能省下上百G。再比如监控不只是看使用率，还得设置 inode 使用告警，有时候小文件太多，空间没满 but inodes 耗尽，照样写不了文件。
还有就是备份策略。别指望修复万能，真遇到物理损坏，fsck 也救不回来。重要数据至少要有两份，异地一份，这才是底线。
上次公司测试机房断电，三台虚拟机宿主硬盘掉线，靠的是前一天的快照+远程 rsync，两小时全拉起来。所以说，修复是应急手段，平时功夫才决定你半夜能不能睡安稳觉。