Мониторинг диска на сервере: частые ошибки и решения

MAATRIX

Диск на сервере ведёт себя странно: df показывает свободное место, а система пишет «no space left»; после удаления гигабайтов логов место не вернулось; du и df расходятся в разы. Всё это классические ловушки работы с диском, и каждая имеет чёткое объяснение. Разберём частые ошибки мониторинга диска на сервере и то, как их диагностировать — с конкретными командами.

df показывает место, а система пишет «нет места»

Самая сбивающая с толку ситуация: df -h показывает, что на разделе свободны гигабайты, но приложения падают с «No space left on device». В 90% случаев причина — закончились не гигабайты, а inode.

Inode — это записи о файлах, и их число ограничено при создании файловой системы. Миллионы мелких файлов (сессии PHP, кэш, очереди писем, временные файлы) исчерпают inode, при этом займут мало места. Проверьте:

df -i

Если в колонке IUse% значение около 100% — вот и причина. Найдите каталог-виновник, посчитав число файлов в подкаталогах:

for d in /var/*; do echo "$(find "$d" -type f 2>/dev/null | wc -l) $d"; done | sort -rn | head

Команда покажет, где скопились миллионы файлов. Обычно это забытый кэш, разросшиеся сессии или очередь почты. Почистите каталог — inode освободятся, и система оживёт. На будущее добавьте мониторинг inode рядом с мониторингом места: df -i так же важен, как df -h.

Удалили файлы, а место не вернулось

Вы удалили большой лог или дамп, du подтверждает, что файла нет, но df по-прежнему показывает занятое место. Это не баг — файл держит открытым живой процесс. В Linux место освобождается только когда закрыт последний дескриптор файла; пока процесс держит удалённый файл открытым, место занято.

Классика — растущий лог, который вы удалили, но сервис (Nginx, приложение) продолжает в него писать через открытый дескриптор. Найдите такие файлы:

lsof +L1

Флаг +L1 показывает файлы с нулём ссылок (удалённые), которые ещё открыты. В выводе будет процесс и путь. Решение — не убивать процесс, а перезапустить его или переоткрыть лог. Для сервисов с логами корректный путь — послать сигнал переоткрытия или перезапустить службу:

systemctl restart nginx

После этого дескриптор закроется и место вернётся. Именно поэтому после чистки логов сервисы часто нужно перезапускать или использовать logrotate с правильной директивой copytruncate или postrotate.

Этот механизм — одна из самых частых причин ночной паники «удалил гигабайты, а сервер всё равно лежит». Понимание тут экономит нервы: в Linux имя файла и сами данные — разные вещи, и rm убирает только имя. Пока хоть один процесс держит открытым дескриптор, данные физически остаются на диске и место не освобождается, сколько бы du ни говорил, что файла нет. Поэтому правильная последовательность при переполнении из-за логов такая: сначала lsof +L1, чтобы найти виновника, затем аккуратный перезапуск именно этого сервиса, и только потом, если нужно, чистка. Слепо удалять файлы и надеяться, что место вернётся, — тупиковый путь, который часто заканчивается лишним даунтаймом.

du и df показывают разные цифры

Вы суммируете размеры через du, получаете 20 ГБ, а df говорит, что занято 45 ГБ. Расхождение сбивает с толку, но объяснимо. Причин несколько.

Первая — те самые удалённые, но открытые файлы из прошлого раздела: du их не видит (файла нет в дереве), а df учитывает (место занято). Вторая — du без sudo не заходит в каталоги, куда нет доступа, и недосчитывает. Запускайте от root. Третья — примонтированные поверх каталога файловые системы: du считает то, что видит сверху, а реальные данные под точкой монтирования. Проверьте, что монтируется и куда:

mount | column -t
du -sh --one-file-system /* 2>/dev/null | sort -rh | head

Флаг --one-file-system не даёт du уходить в другие смонтированные ФС и убирает путаницу. Если после всех проверок расхождение сохраняется, почти наверняка виноваты открытые удалённые файлы — вернитесь к lsof +L1.

Ложные или запоздалые алерты

Мониторинг диска настроен, но алерт пришёл, когда диск уже был полон, — или, наоборот, срабатывает на ровном месте. Разберём обе беды.

Запоздалый алерт обычно означает слишком высокий порог или редкую проверку. Если порог 95%, а диск заполняется рывком (большой дамп), между 95% и 100% пройдут секунды — реагировать поздно. Ставьте порог с запасом (80–85%) и проверяйте чаще. Ложные срабатывания бывают, когда мониторится раздел, который штатно работает под завязку (например, отдельный раздел под кэш). Настраивайте пороги per-раздел, а не один на всё. И учтите tmpfs и подобные разделы в памяти: они «заполняются» иначе, их часто исключают из алертов, чтобы не шуметь.

Полезно мониторить не только текущий процент, но и скорость роста. Диск, стабильно занятый на 80%, менее опасен, чем диск, который за час прыгнул с 40% до 70%: второй сигнализирует об аномалии — вышедшем из-под контроля логе, утечке или атаке. Продвинутые системы вроде Prometheus умеют предсказывать заполнение по тренду и алертить «при такой скорости диск кончится через N часов», что куда полезнее статичного порога. Но даже простой скрипт можно научить сравнивать текущее значение с предыдущим и слать отдельный алерт на резкий скачок — это ловит проблемы, которые статичный порог замечает слишком поздно.

Диск быстро заполняется снова после чистки

Почистили диск, а через день он снова полон — значит, вы боретесь со следствием, а не с причиной. Что-то активно генерирует данные, и это надо найти, а не чистить по кругу.

Чаще всего виноваты неограниченные логи. Проверьте размер журналов systemd и ограничьте его:

journalctl --disk-usage
journalctl --vacuum-size=500M

Затем задайте постоянный лимит в /etc/systemd/journald.conf параметром SystemMaxUse=500M. Проверьте, работает ли logrotate для остальных логов (/etc/logrotate.d/), нет ли приложения в цикле ошибок, которое пишет гигабайты в лог за час, и не копятся ли старые дампы базы без ротации. Найдя источник, вы решаете проблему навсегда, а не до завтра.

Если же диск заполняется потому, что данных объективно стало больше, честный вывод один — текущий объём мал для задачи. Переход на VPS с большим диском решает это без ежедневной борьбы. У MAATRIX сервер с нужным объёмом поднимается за пару минут, с оплатой картой РФ, СБП или криптой — иностранная карта не требуется.

Частые вопросы