Как быстро проверить использование диска в Linux: от паники до контроля за 5 минут

Три часа ночи. Ваш сервер начинает тормозить. Логи не пишутся. База данных отказывается принимать новые записи. Панель мониторинга светится красным. Первая мысль: «DDoS? Взлом? Отказ железа?»

А потом вы открываете консоль и видите простое, но убийственное сообщение: "No space left on device".

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

Звучит знакомо? Тогда эта статья для вас. Сегодня разберём, как быстро диагностировать проблемы с дисковым пространством в Linux, найти файлы-пожиратели места и настроить систему так, чтобы больше никогда не просыпаться от подобных сюрпризов.

Почему переполненный диск — это катастрофа

Переполненный диск — это не просто неудобство. Это серьёзная проблема, которая может привести к:

• Остановке работы базы данных: PostgreSQL, MySQL и другие СУБД не могут записывать новые данные без свободного места.
• Потере логов: Система перестаёт записывать важную диагностическую информацию именно тогда, когда она вам нужна больше всего.
• Невозможности обновления: Менеджеры пакетов требуют временного места для распаковки и установки обновлений.
• Зависанию приложений: Многие программы создают временные файлы во время работы и падают, если не могут этого сделать.
• Повреждению данных: В некоторых случаях резкое отсутствие места может привести к повреждению файловой системы.

По статистике системных администраторов, около 15% всех инцидентов в production-среде связаны с проблемами дискового пространства. И самое обидное — большинство из них можно было предотвратить простым мониторингом.

df: быстрая диагностика за секунды

Команда df (disk free) — это ваш первый инструмент для оценки ситуации. Она показывает общую картину использования дискового пространства во всех смонтированных файловых системах.

Базовое использование

Самый простой способ проверить диск:

df -h

Флаг -h (human-readable) показывает размеры в удобном для человека формате — гигабайтах и мегабайтах вместо килобайтных блоков.

Пример вывода:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   42G   8.0G  85% /
/dev/sdb1       200G  180G   20G   90% /var/www
tmpfs           7.8G  120K  7.8G   1% /dev/shm

Что означают эти колонки?

• Filesystem: Название устройства (например, /dev/sda1 — первый раздел первого диска).
• Size: Общий размер файловой системы.
• Used: Использовано места.
• Avail: Доступно свободного места.
• Use%: Процент заполненности — это самая важная цифра.
• Mounted on: Точка монтирования — где эта файловая система доступна в системе.

Критические пороги

Вот на что нужно обращать внимание:

• 85-90% — Пора начинать планировать очистку или расширение.
• 90-95% — Критический уровень, нужно действовать срочно.
• 95%+ — Аварийная ситуация, система может начать давать сбои в любой момент.

Важный нюанс: Linux резервирует 5% места на корневом разделе для системных процессов и root-пользователя. Поэтому даже при показателях в 95% у вас уже могут возникать проблемы с записью для обычных пользователей.

Полезные опции df

Проверить конкретную директорию:

df -h /var/log

Эта команда покажет информацию о файловой системе, на которой находится /var/log.

Посмотреть тип файловой системы:

df -Th

Добавляет колонку с типом ФС (ext4, xfs, btrfs и т.д.). Полезно, когда у вас несколько разных типов файловых систем.

Проверить использование inodes:

df -ih

Inode — это специальная структура данных, которая хранит метаинформацию о каждом файле. Можно исчерпать inodes, даже если на диске ещё есть место. Это происходит, когда у вас миллионы мелких файлов (например, кеш, логи, почтовые ящики).
Признак проблемы: диск показывает свободное место, но система жалуется на его отсутствие. В этом случае проверяйте inodes.

du: детективная работа по поиску проблемы

Команда df показала, что диск забит. Отлично. Но что именно занимает всё место? Для этого используется команда du (disk usage).

Поиск самых больших директорий

Вот команда, которую я использую чаще всего для быстрой диагностики:

du -h --max-depth=1 / | sort -hr | head -20

Разберём, что здесь происходит:

• du -h --max-depth=1 / — показывает размер всех директорий на глубине 1 уровня от корня.
• sort -hr — сортирует результаты по размеру (от большего к меньшему).
• head -20 — показывает только топ-20 самых больших.

Пример вывода:

42G    /var
15G    /usr
8.5G   /home
2.1G   /opt
850M   /tmp

Теперь вы сразу видите, что проблема в /var. Идём глубже:

du -h --max-depth=1 /var | sort -hr | head -20

И так далее, пока не найдёте конкретную директорию или файл, который съел всё место.

Поиск больших файлов

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

Найти все файлы больше 1 ГБ:

find / -type f -size +1G -exec ls -lh {} \; 2>/dev/null

Или еще удобнее — найти 20 самых больших файлов в системе:

find / -type f -exec du -h {} \; 2>/dev/null | sort -rh | head -20

Внимание: эта команда может работать долго на больших файловых системах. Лучше сначала ограничить поиск конкретной директорией:

find /var -type f -size +1G -exec ls -lh {} \; 2>/dev/null

Почему логи — главный враг свободного места

В 80% случаев проблемы с дисковым пространством виноваты логи. Особенно если:

• У вас отключена ротация логов.
• Приложение пишет логи в debug-режиме на продакшене.
• Где-то ошибка в коде, генерирующая миллионы повторяющихся записей

Проверьте размер директории с логами:

du -sh /var/log

И посмотрите на отдельные файлы:

du -h /var/log/* | sort -rh | head -10

Практические сценарии: что делать в разных ситуациях

Сценарий 1: Раздувшийся log-файл

Проблема: Один файл лога занял 30 ГБ из 50.

Быстрое решение:

НЕ удаляйте файл! Это может сломать приложение.

Вместо этого очистите его содержимое: /var/log/application.log

Или урежьте до последних 1000 строк:

tail -n 1000 /var/log/application.log > /tmp/temp.log

mv /tmp/temp.log /var/log/application.log

Долгосрочное решение: Настройте logrotate для автоматической ротации:

/etc/logrotate.d/application
/var/log/application.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 644 www-data www-data
}

Сценарий 2: Миллионы мелких файлов

Проблема: Кеш-директория содержит миллионы файлов по 1-2 КБ каждый.

Диагностика:

Посчитать количество файлов:

find /var/cache/application -type f | wc -l

Если там больше 100 000 файлов — это, скорее всего, ваша проблема.

Быстрое решение.

Удалить файлы старше 7 дней:

find /var/cache/application -type f -mtime +7 -delete

Или удалить всё:

rm -rf /var/cache/application/*

Сценарий 3: Забытые бэкапы

Проблема: Старые бэкапы занимают 150 ГБ.

Диагностика:

du -sh /var/backups
ls -lht /var/backups | head

Решение: Удалите старые бэкапы и настройте автоматическую очистку.

Оставить только последние 5 бэкапов:

cd /var/backups
ls -t | tail -n +6 | xargs rm -f

Или удалить бэкапы старше 30 дней:

find /var/backups -type f -name "*.sql.gz" -mtime +30 -delete

Сценарий 4: Docker пожирает место

Проблема: Docker накопил гигабайты неиспользуемых образов, контейнеров и volumes.

Диагностика:

docker system df

Быстрая очистка.

Удалить остановленные контейнеры, неиспользуемые сети и образы:

docker system prune -a

Удалить всё, включая volumes (ОСТОРОЖНО!):

docker system prune -a --volumes

Типичные ошибки и как их избежать

Ошибка 1: Удаление файла, который всё ещё используется

Проблема: Вы удалили огромный лог-файл, но место не освободилось.

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

Решение: Найдите процесс, который держит удалённый файл:

lsof | grep deleted

И перезапустите этот процесс.

Ошибка 2: Очистка /tmp без проверки

Проблема: Удалили всё в /tmp, сломали работающие приложения.

Правильный способ: Удаляйте только старые файлы:

find /tmp -type f -atime +10 -delete

Ошибка 3: Игнорирование резервированного места

Даже при показателях df в 90%, для обычных пользователей может не быть свободного места из-за 5% резерва для root.

Решение: Уменьшите резерв на не-системных разделах.

Уменьшить резерв с 5% до 1% поможет:

tune2fs -m 1 /dev/sdb1

Ошибка 4: Запуск поиска на корневом разделе под нагрузкой

Проблема: Команда find - грузит диск и замедляет систему.

Решение: Используйте ionice для понижения приоритета:

ionice -c3 find / -type f -size +1G

Продвинутые техники

Быстрый поиск с ncdu

ncdu — это интерактивный анализатор дискового пространства с удобным интерфейсом:

Установка:

apt install ncdu  # Debian/Ubuntu
yum install ncdu  # CentOS/RHEL

Использование:

ncdu /var

Вы получите интерактивный список директорий с возможностью навигации стрелками и удаления файлов прямо из интерфейса.

Комбинирование команд для детального анализа

Найти самые большие директории в /var с подробностями:

du -ah /var | sort -rh | head -20

Найти файлы, изменённые за последние 24 часа и занимающие больше 100 МБ:

find /var -type f -mtime -1 -size +100M -exec ls -lh {} \;

Показать топ-10 директорий по количеству файлов:

for dir in /var/*/; do 
  echo -n "$dir: "; 
  find "$dir" -type f | wc -l; 
done | sort -t: -k2 -rn | head -10

Мониторинг в реальном времени

Смотреть, какие файлы изменяются прямо сейчас:

watch -n 1 'df -h; echo "---"; du -sh /var/*'

Или установите iotop для мониторинга дисковой активности:

apt install iotop

Показывать только активные процессы:

iotop -o

Как понять, что пора чистить: 7 признаков

1. Замедление работы: Система стала тормозить без видимых причин.
2. Ошибки в логах: Сообщения типа "No space left" или "Disk quota exceeded".
3. Проблемы с базой данных: MySQL/PostgreSQL отказываются принимать новые записи.
4. Невозможность установить обновления: Менеджер пакетов жалуется на нехватку места.
5. Ошибки при создании файлов: Приложения падают при попытке сохранить данные.
6. Заполненность выше 85%: Даже если всё работает, это сигнал к действию.
7. Резкий рост использования: Если за неделю использование выросло на 20%+ — где-то утечка.

Профилактика: настройте и забудьте

1. Ротация логов

Убедитесь, что logrotate настроен правильно.

Проверить конфигурацию:

cat /etc/logrotate.conf
ls /etc/logrotate.d/

Протестировать ротацию в dry-run режиме:

logrotate -d /etc/logrotate.conf

2. Автоматическая очистка /tmp

Добавьте в cron ежедневную очистку.

Очищать файлы старше 7 дней:

0 3 * * * find /tmp -type f -atime +7 -delete

3. Мониторинг Docker

Если используете Docker, настройте автоматическую очистку.

Добавьте в cron еженедельную очистку:

0 2 * * 0 docker system prune -f

Заключение: держите диск под контролем

Проблемы с дисковым пространством — одна из самых частых причин сбоев в Linux-системах. Но при правильном подходе их легко предотвратить:

1. Регулярно мониторьте использование диска с помощью df -h.
2. Используйте du для быстрого поиска проблемных директорий.
3. Автоматизируйте мониторинг с помощью скриптов и уведомлений.
4. Настройте ротацию логов и автоматическую очистку временных файлов.
5. Действуйте проактивно: не ждите, пока диск заполнится до 95%.

Помните: гораздо проще потратить 10 минут на настройку мониторинга, чем час на аварийную очистку диска в три часа ночи.

Хотите хостинг, где о дисковом пространстве можно не беспокоиться? 

THE.Hosting предлагает VPS и выделенные серверы с NVMe RAID 10 и возможностью быстрого масштабирования. Закончилось место? Увеличьте диск за пару кликов без простоя системы.