Linux 服务器磁盘满了怎么安全清理？不要一上来就删日志
Linux 磁盘满要先定位分区、目录和文件类型，再决定清理日志、缓存、备份还是数据库文件。本文强调安全清理顺序和不能误删的位置。
Linux 服务器磁盘满，影响的不只是“不能再上传文件”。它可能导致数据库无法写入、日志写入失败、服务启动失败，严重时系统进入只读或异常状态。清理时最重要的不是删得快，而是先判断哪些文件能删、哪些文件不能碰。
先确定哪个分区满
df -h如果 `/` 满了，系统和多数服务都会受影响；如果 `/var` 满了，常见影响是日志、数据库和缓存；如果单独的数据盘满了，要看网站、备份或数据库是否放在上面。
再看 inode：
df -i容量没满但 inode 满，也会无法创建新文件。大量 session、缓存、小图片、邮件队列都可能造成 inode 用尽。
找目录，不要直接删文件
du -h --max-depth=1 / 2>/dev/null | sort -h找到大目录后再逐级看：
du -h --max-depth=1 /var 2>/dev/null | sort -h常见大户是 `/var/log`、网站上传目录、备份目录、数据库目录、Docker 目录和缓存目录。排查时要先确认目录用途，不要看到大就删。
不同文件不同处理
| 类型 | 可以怎么处理 | 风险 |
|---|---|---|
| 普通访问日志 | 截断、压缩、日志轮转 | 删除正在占用的日志可能不释放空间 |
| 旧备份包 | 确认已有异地备份后删除 | 误删会影响恢复 |
| 缓存文件 | 用程序或面板清理 | 可能影响当前会话 |
| 数据库文件 | 按数据库规则处理 | 不能直接删除 |
大日志确认后可以截断：
truncate -s 0 /path/to/logfile如果直接 `rm` 一个正在被进程打开的日志文件，空间可能不会马上释放，因为进程仍持有文件句柄。可以通过重启对应服务释放句柄，但生产环境要评估影响。
数据库相关文件要特别谨慎
MySQL 数据目录、binlog、ibdata 文件不能随意删除。binlog 占用高时，应先确认备份和主从需求，再按数据库规则清理。数据库目录满导致写入失败时，最好先降低写入压力，再处理空间。
如果磁盘满已经导致 MySQL 无法启动，先不要反复启动。应保留错误日志，确认空间恢复后再检查数据表状态。
清完还要防止再次写满
配置日志轮转，限制备份保留周期，监控磁盘使用率，检查异常访问是否导致日志暴增。只清理空间不处理来源，磁盘很快还会满。
用户可以自行定位大目录、清理确认无风险的旧备份和普通日志。若系统只读、数据库异常、文件系统损坏或无法启动，应通过控制台、救援模式或服务商协助处理。