Диск заполняется: как поймать до падения сайта

Заполненный диск — тихий убийца: MySQL не пишет, логи не ротируются, сессии не создаются. Пользователь видит белый экран или 500, а вы узнаёте последним. Разбор причин и порогов.

Кто съедает место чаще всего

1. /var/log — nginx, php-fpm, mysql без logrotate или с уровнем debug.
2. Бэкапы на том же диске — backup*.sql.gz копятся годами. Отдельный разбор →
3. /tmp и сессии PHP — миллионы файлов sess_*.
4. upload / bitrix/cache — на Bitrix кэш и выгрузки маркетплейса.
5. Docker images — если на том же VPS есть контейнеры.

du -xhd1 / 2>/dev/null | sort -hr | head -15
find /var/log -type f -size +100M 2>/dev/null
find /tmp -type f -name 'sess_*' 2>/dev/null | wc -l

Какие пороги алертов ставить

• 80% — предупреждение: есть время почистить без аврала.
• 90% — срочно: в ближайшие часы возможен отказ записи.
• Тренд +5% за сутки — отдельный сигнал (утечка логов, битый cron бэкапа).

Первые 30 минут при срабатывании алерта

1. df -h — какой раздел, сколько осталось.
2. Найти топ-каталоги du, не удалять вслепую.
3. Сжать или удалить старые логи (с копией, если нужен разбор инцидента).
4. Проверить cron бэкапов — не пишет ли дважды в один каталог.
5. После освобождения 15%+ — проверить сайт и systemctl status mysql nginx.

Один error.log на 18 ГБ: logrotate и journald

Классика с хостинга: debug «временно» включили после обновления — и забыли. В /var/log один файл (nginx, php-fpm, приложение) раздувается до десятков гигабайт. Диск 99%, MySQL не пишет — а «решение» покупка места вместо ротации.

# Кто съел /var/log
du -sh /var/log/* 2>/dev/null | sort -hr | head -10

# Крупные файлы по всему диску
find /var/log -type f -size +100M 2>/dev/null

# Logrotate для nginx (пример /etc/logrotate.d/nginx)
/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

После правки — sudo logrotate -d /etc/logrotate.conf (dry-run), затем принудительно для одного файла: sudo logrotate -f /etc/logrotate.d/nginx.

journald — отдельный пожиратель на systemd-серверах:

# Сколько занимает журнал
journalctl --disk-usage

# Ограничить, например, 500 МБ ( /etc/systemd/journald.conf )
SystemMaxUse=500M

sudo systemctl restart systemd-journald

Профилактика

• Logrotate на все сервисы, лимит размера journald (см. выше).
• Бэкапы на отдельный volume или S3 — чеклист бэкапов.
• Мониторинг диска с историей — видно, когда начался рост (деплой? импорт?).