Шпаргалка по df и du: Диагностика дискового пространства в Linux

Быстрый старт: df и du за 30 секунд

Диск заполнен под завязку, приложение упало, сервер не отвечает - знакомая ситуация для любого администратора. Первое, что нужно сделать - локализовать проблему. Две команды дают мгновенный срез состояния файловых систем и каталогов.

df -h показывает занятое и свободное место на всех смонтированных разделах в человекочитаемом формате. Вывод выглядит так:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   45G  2.5G  95% /
/dev/sdb1       200G  120G   80G  60% /data
tmpfs           3.9G   12M  3.9G   1% /dev/shm

Столбцы, которые важны прямо сейчас: Use% - процент заполнения, Avail - доступное место в гигабайтах, Mounted on - точка монтирования. Если Use% подобрался к 100% на корневом разделе - действовать нужно немедленно.

du -sh /путь выводит суммарный размер указанного каталога. Для текущей директории команда выглядит как du -sh . и возвращает что-то вроде 4.2G .. Это точка входа в расследование: вы видите, сколько весит конкретная папка, и можете спускаться глубже.

Эти две утилиты - фундамент диагностики. Дальше разберём каждую детально, с флагами, сценариями и подводными камнями.

df: мониторинг файловых систем

Утилита df читает суперблоки файловых систем и возвращает агрегированную информацию об использовании дискового пространства. Она не суммирует размеры файлов - она спрашивает у ядра, сколько блоков занято и сколько свободно на уровне всей ФС. Это ключевое отличие от du, которое мы разберём позже.

Ключевые опции df: от -h до -i

Базовый вызов df без флагов выводит размеры в килобайтах - читать неудобно. Соберите в рабочий арсенал эти опции:

Пример вывода df -i:

Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sda1      3276800 315000 2961800   10% /

Если IUse% приближается к 100%, система не сможет создавать новые файлы, даже если свободное место в гигабайтах ещё есть. Такое случается с почтовыми серверами, сессионными хранилищами и контейнерными рантаймами, плодящими мелкие файлы.

Почему df и du показывают разное: открытые файлы и удалённые данные

Классическая головоломка: df -h кричит о 100% заполнении, а du -sh / показывает значительно меньшую цифру. Причина - удалённые, но всё ещё открытые файлы.

Сценарий: приложение пишет лог в /var/log/app.log. Вы удаляете этот файл через rm /var/log/app.log, но процесс продолжает держать файловый дескриптор открытым. Запись в лог идёт, место занято, а du его не видит - файла-то в каталоге уже нет. Ядро освободит блоки только когда процесс закроет дескриптор или завершится.

Найти процессы-нарушители:

lsof | grep deleted

Вывод покажет PID, пользователя и путь к удалённому файлу с пометкой (deleted). Дальше - перезапуск сервиса или, в крайнем случае, kill процесса. После этого df и du сойдутся в показаниях.

Эта ситуация - частая причина ночных инцидентов на продакшене. Мониторинг производительности сервера: метрики CPU, памяти, диска и сети помогает выявить проблему до того, как раздел заполнится полностью.

du: оценка размеров каталогов и поиск «пожирателей» места

Если df даёт общую картину, то du - инструмент для расследования. Он рекурсивно обходит дерево каталогов и суммирует размеры всех файлов внутри. Результат - точный вес каждой директории.

Основные флаги, которые стоит запомнить:

• -h - человекочитаемый формат.
• -s - только суммарный размер, без детализации по подкаталогам.
• -c - добавляет строку с общим итогом в конце вывода.
• --max-depth=N - ограничивает глубину рекурсии. --max-depth=1 показывает размеры подкаталогов первого уровня.

Типовой сценарий: нужно понять, что раздувает корневой раздел. Команда du -h --max-depth=1 / | sort -hr выводит директории верхнего уровня, отсортированные по размеру от большего к меньшему. Вы сразу видите, что /var занимает 30 ГБ, /home - 15 ГБ, а /usr - 8 ГБ. Дальше спускаетесь в /var и повторяете.

Исключение каталогов при обходе: du -h --max-depth=1 / --exclude=/proc --exclude=/sys. Это ускоряет работу и убирает виртуальные ФС, которые не занимают места на диске.

Топ-10 самых больших файлов с помощью find и du

Иногда нужно найти не каталог, а конкретные файлы-гиганты: забытый дамп базы данных, ISO-образ или несжатый лог. Готовая команда:

find / -type f -exec du -Sh {} + 2>/dev/null | sort -rh | head -10

Как это работает: find / -type f ищет все файлы, начиная с корня. -exec du -Sh {} + передаёт найденные файлы в du, который вычисляет размер каждого. 2>/dev/null глушит ошибки доступа. sort -rh сортирует по убыванию, head -10 оставляет топ-10.

Адаптируйте путь под задачу: find /var/log -type f -exec du -Sh {} + 2>/dev/null | sort -rh | head -10 покажет крупнейшие логи. Альтернатива с xargs: find / -type f -print0 | xargs -0 du -Sh | sort -rh | head -10. Оба варианта работают, первый чуть компактнее.

Обнаружение скрытых накопителей: /tmp, /var/log и другие

Система может быть забита не только легитимными данными. Временные файлы, неконтролируемые логи и кэш - частые виновники переполнения. Проверьте эти каталоги в первую очередь:

• /tmp - сессионные файлы, временные загрузки, результаты работы скриптов.
• /var/log - логи, которые забыли настроить на ротацию.
• /var/cache - кэш пакетных менеджеров (apt, yum/dnf), кэш приложений.
• /root/.cache - кэш, создаваемый процессами, запущенными от root.

Быстрая проверка всех точек одной командой:

du -sh /tmp /var/log /var/cache /root/.cache 2>/dev/null

Скрытые файлы и каталоги (начинающиеся с точки) обычный du -sh * не показывает. Используйте du -sh .[!.]* в целевом каталоге, чтобы увидеть и их.

Утечки в /tmp: как найти и безопасно очистить

/tmp - особая зона риска. Многие приложения создают там временные файлы и не всегда подчищают за собой. Проверка размера: du -sh /tmp. Если цифра аномально большая - ищем старые файлы:

find /tmp -type f -mtime +7

Эта команда покажет файлы, не изменявшиеся более 7 дней. Перед удалением убедитесь, что они не используются процессами:

fuser /tmp/подозрительный_файл

Если fuser ничего не вернул - файл можно удалять. Безопасная очистка /tmp от старого мусора: find /tmp -type f -mtime +7 -delete. Для регулярной профилактики настройте tmpwatch или systemd-tmpfiles-clean - они автоматизируют эту задачу.

Логи в /var/log требуют другого подхода. Вместо ручного удаления настройте logrotate с политиками ротации, сжатия и хранения. Практический анализ логов Nginx и Apache: готовые команды grep и awk поможет не только найти ошибки, но и понять, какие логи стоит ротировать агрессивнее.

Профилактика: простой мониторинг и автоматические алерты

Реагировать на заполнение диска постфактум - плохая практика. Настройте оповещения, чтобы узнавать о проблеме до того, как она обрушит сервис.

Минимальный вариант - cron-скрипт, который шлёт письмо при превышении порога:

#!/bin/bash
THRESHOLD=90
CURRENT=$(df / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$CURRENT" -gt "$THRESHOLD" ]; then
  df -h | mail -s "Disk alert: root partition at ${CURRENT}%" admin@example.com
fi

Поставьте этот скрипт в cron на ежечасное выполнение, и вы получите базовое покрытие. Для более серьёзных сред используйте системы мониторинга - Zabbix или Nagios со стандартными шаблонами проверки дискового пространства. Они умеют строить графики, предсказывать дату заполнения и слать алерты в мессенджеры.

Интерактивный анализ в реальном времени удобно проводить через ncdu - консольный файловый менеджер, который показывает дерево каталогов с размерами и позволяет перемещаться по нему стрелками. Установка: apt install ncdu или dnf install ncdu. Запуск: ncdu /. Навигация интуитивная, удаление файлов - по нажатию d.

Мониторинг производительности сервера даёт более широкий взгляд на метрики диска, включая iowait и latency, которые часто сопутствуют проблемам заполнения.

Шпаргалка: все команды в одном месте

Сводная таблица для быстрого возврата к материалу. Копируйте, вставляйте, решайте проблему.

Держите эту шпаргалку под рукой. Когда диск заполнится в пятницу вечером, вы потратите на диагностику минуты, а не часы.