先确认是不是磁盘真的满了
Linux 服务器突然提示 No space left on device，很多人第一反应是磁盘容量不够，于是直接清理几个大文件，甚至急着扩容。但实际线上排障里，“写不进去”不一定只代表分区空间耗尽，也可能是 inode 用完、日志目录权限异常、临时目录被挂载为只读，或者某个服务把大量小文件堆满了目录。
第一步建议先看整体空间，而不是盯着单个目录猜原因。常用命令是 df -h，它可以看到各个挂载点的容量、已用空间和使用率。重点观察网站目录、数据库目录、日志目录、临时目录所在的分区，例如 /、/var、/home、/data 等。
如果某个分区已经 100%，说明容量层面确实需要处理；如果空间还有很多，但程序仍然报写入失败，就要继续检查 inode、权限和文件系统状态。不要只看 du -sh /，因为跨挂载点、隐藏文件、已删除但仍被进程占用的文件，都可能让表面结果和真实占用不一致。
对生产服务器来说，排查顺序应该是“确认现象、定位分区、找到来源、再决定清理方式”。直接删除未知文件最危险，尤其是数据库文件、网站附件、缓存索引和运行中的日志文件，删错之后恢复成本往往比扩容还高。
用 df 和 du 找到占用来源
当 df -h 显示某个挂载点使用率很高时，下一步才用 du 去找目录级占用。比如根分区紧张，可以从 du -h --max-depth=1 / 2>/dev/null | sort -h 开始；如果是 /var 较大，就继续进入 /var 做同样的统计。
很多网站服务器的空间问题集中在几个位置：Nginx 或 Apache 访问日志、PHP 错误日志、数据库备份包、上传目录、临时压缩包、缓存目录、Docker 镜像和容器日志。它们共同特点是增长比较隐蔽，平时不影响业务，一旦触顶就会让写入、上传、登录、定时任务全部异常。
需要注意的是，du 统计的是目录里当前能看到的文件大小，而 df 反映的是文件系统实际已使用空间。如果两者差距很大，很可能是某些大日志已经被删除，但进程还在持有文件句柄，空间并没有真正释放。这时要检查被删除但仍占用空间的文件。
可以使用 lsof | grep deleted 观察是否有进程占着已删除文件。常见场景是手动删除了 Nginx 日志、PHP-FPM 日志或应用日志，但服务没有重新打开日志文件，磁盘空间仍然被旧句柄占用。正确处理通常是重载或重启对应服务，让它释放文件句柄，而不是继续盲目删除更多文件。
小文件太多时要检查 inode
如果 df -h 显示空间还够，但程序仍然提示没有空间，下一步要执行 df -i。inode 可以理解为文件系统用来记录文件元信息的“名额”，每个文件、目录通常都会占用一个 inode。大量小文件会先耗尽 inode，即使磁盘容量还有剩余，也无法继续创建新文件。
inode 耗尽常见于缓存目录、会话文件、邮件队列、图片缩略图、临时上传目录、爬虫生成的小文件、队列失败记录等。它和“大文件占满磁盘”的处理方式不同：inode 问题要找的是文件数量最多的目录，而不是体积最大的目录。
可以用 find /path -xdev -type f | wc -l 粗略统计某个目录下文件数量，也可以用分层脚本逐级定位小文件集中点。排查时尽量限定路径和挂载点，避免在整台机器上无差别扫描，导致 I/O 压力升高。
处理 inode 问题时，优先清理过期缓存、过期 session、临时文件和已确认可删除的队列文件。对于网站附件、用户上传内容、业务日志归档等目录，不要因为文件多就直接删，要先确认业务含义、保留周期和备份状态。
日志、备份和缓存最容易失控
日志是最常见的磁盘杀手。访问量突然上升、错误日志刷屏、调试模式忘记关闭、反向代理重复记录请求，都可能让日志在短时间内暴涨。排查时可以重点查看 /var/log、站点日志目录、应用自定义日志目录以及容器日志位置。
备份文件也容易被忽略。很多站点会把数据库备份、网站整包、图片压缩包直接放在服务器本地，并且没有自动过期策略。短期看很方便，长期看会形成一堆相似的压缩包，真正出问题时还分不清哪份能恢复。
缓存目录则要区别对待。页面缓存、对象缓存、缩略图缓存、构建缓存通常可以重建，但不同程序的缓存清理方式不一样。WordPress、Laravel、Node.js、Java 应用各自都有自己的缓存目录和清理命令，最好按程序文档或现有运维规范处理，不要跨目录硬删。
如果业务已经跑在云服务器上，也可以结合监控和告警提前发现增长趋势。比如使用 速维云服务器 承载网站时，除了关注 CPU、内存和带宽，也应该把磁盘使用率、inode 使用率、日志增长速度纳入日常巡检。这样能在磁盘触顶前处理，而不是等网站上传失败、数据库写入失败后再救火。
清理前先判断文件能不能删
磁盘紧张时最忌讳“看到大文件就删”。比较稳妥的做法是先分三类：确认可删除、需要归档后删除、不能直接删除。确认可删除的通常包括过期临时文件、旧缓存、明确无用的安装包和重复压缩包；需要归档后删除的可能是历史日志、历史备份和业务导出文件；不能直接删除的包括数据库数据文件、正在写入的日志、程序上传目录和未知配置文件。
对于日志文件，推荐使用日志轮转，而不是长期手动清理。Linux 常见方案是 logrotate，可以按天、按大小切割日志，保留固定份数，并在切割后通知服务重新打开日志文件。这样既能控制空间，也保留了必要的排障线索。
对于备份文件，建议建立保留策略，例如最近 7 天每日备份、最近 4 周每周备份、最近 3 个月每月备份。保留策略要结合业务恢复目标来定，而不是只看磁盘是否够用。备份如果从来没有恢复演练，也不能算真正可靠。
对于缓存文件，优先使用程序提供的清理入口。比如网站后台缓存插件、框架命令、对象存储同步工具、构建系统清理命令等。只有确认缓存可再生、且程序当前没有依赖这些文件时，再做批量删除。
临时止血和长期治理要分开
如果服务器已经因为磁盘满导致业务异常，第一目标是快速恢复写入能力。可以先压缩或转移旧日志、清理过期临时文件、删除确认无用的大包、重载持有已删除日志的服务，让磁盘使用率降到安全线以下。这个阶段动作要少而准，避免在高压状态下扩大故障。
恢复后再做长期治理：为日志配置轮转，为备份设置保留周期，为上传目录和缓存目录设置容量监控，为数据库和网站附件规划独立磁盘或对象存储。如果业务增长明显，还要评估磁盘 I/O、快照策略和扩容方式，而不是每次满了才临时清理。
网站类业务还要留意“磁盘空间”和“磁盘性能”不是一回事。空间够不代表写入快，特别是数据库、搜索索引、图片处理和大量小文件读写，对 I/O 延迟非常敏感。如果经常出现磁盘等待高、备份期间网站明显变慢，就要把存储性能也纳入排查。
当你不确定该删什么时，宁可先移动到临时归档目录、确认业务正常后再删除，也不要直接不可逆清理。生产环境里，最好的排障不是动作最多，而是每一步都知道目的、影响和回滚方式。
一套安全的排查顺序
最后把流程整理成一套顺序：先用 df -h 看哪个挂载点满了；再用 du --max-depth 找大目录；如果空间看着够却写不了，用 df -i 查 inode；如果 df 和 du 差距大，用 lsof | grep deleted 查被进程占用的已删除文件；确认来源后，再按日志、备份、缓存、临时文件、业务文件分类处理。
清理完成后，还要复查服务状态和业务功能。网站能打开不代表全部恢复，还要检查上传、登录、下单、后台保存、定时任务、数据库写入等动作是否正常。如果之前因为磁盘满导致数据库或缓存异常，还要查看应用日志，确认没有遗留错误。
更重要的是补上预防措施：磁盘使用率超过 80% 告警，inode 使用率超过 80% 告警，日志轮转生效检查，备份保留策略检查，关键目录增长趋势检查。磁盘问题并不复杂，复杂的是它常常被拖到业务出错才被看见。
一台服务器是否稳定，不只看配置参数，也看日常治理是否到位。把磁盘排查从“临时救火”变成“固定巡检”，网站遇到突发流量、日志刷屏或程序异常时，恢复速度会快很多，误删和误判的风险也会低很多。
