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

Заполненный диск — тихий убийца: 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.

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

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