На сервере закончилось место: что проверить в первую очередь

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

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

Проверить свободное место

Начать с df:

df -h

Важно смотреть не только общий диск, но и конкретный раздел. Например, / может быть заполнен, а /home свободен. Или наоборот.

Найти крупные директории

Команда du помогает понять, где место занято.

du -h --max-depth=1 /var | sort -h
du -h --max-depth=1 /home | sort -h
du -h --max-depth=1 /var/www | sort -h

Для сайта:

du -h --max-depth=1 /var/www/site.ru | sort -h

Обычно крупными оказываются uploads, logs, backups, cache, storage, database dumps или vendor-архивы.

Логи

Логи могут расти бесконечно, если нет ротации или приложение пишет слишком подробно.

find /var/log -type f -size +500M -exec ls -lh {} \;
find /var/www/site.ru -type f -name "*.log" -size +100M -exec ls -lh {} \;

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

: > /var/www/site.ru/runtime/logs/app.log

Удаление файла, который держит процесс, может не освободить место до перезапуска процесса. Обнуление в таком случае безопаснее.

Бэкапы и дампы

В корне сайта или домашней директории часто лежат старые архивы:

find /var/www -type f \( -name "*.zip" -o -name "*.tar.gz" -o -name "*.sql" -o -name "*.sql.gz" \) -exec ls -lh {} \;

Архивы в публичной директории — ещё и риск безопасности. Их нужно переносить во внешнее хранилище или закрытую директорию.

Кэш

Кэш приложения может занимать много места. Но чистить его нужно с пониманием проекта.

du -h --max-depth=1 /var/www/site.ru/runtime
du -h --max-depth=1 /var/www/site.ru/web/assets

Обычно кэш можно очистить, но после этого сайт может временно создавать его заново и работать медленнее.

Uploads

Папка uploads растёт естественно. Но в ней могут быть временные файлы, старые импорты, оригиналы изображений, которые больше не используются, и дубли.

du -h --max-depth=2 /var/www/site.ru/web/uploads | sort -h

Удалять пользовательские файлы без проверки нельзя. Лучше сначала найти временные директории и старые импортные файлы.

MySQL binlog

Если место занято в /var/lib/mysql, причиной могут быть бинарные логи.

du -h --max-depth=1 /var/lib/mysql | sort -h
mysql -e "SHOW BINARY LOGS;"

Удалять binlog через rm нельзя. Используют PURGE BINARY LOGS и учитывают репликацию.

PURGE BINARY LOGS BEFORE '2026-06-01 00:00:00';

Docker

Если проект использует Docker, место могут занимать старые images, containers, volumes и logs.

docker system df
docker ps -a
docker images

docker system prune может удалить лишнее, но с volumes нужно быть осторожным: там могут быть данные базы.

После освобождения места

Когда место освобождено, нужно проверить сервисы:

systemctl status nginx
systemctl status php8.2-fpm
systemctl status mysql

И обязательно посмотреть свежие ошибки:

tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/php-fpm/error.log

Чек-лист

1. Проверить df -h.
2. Найти крупные директории через du.
3. Проверить логи приложения и сервера.
4. Найти старые архивы и дампы.
5. Проверить кэш приложения.
6. Проверить uploads и временные файлы.
7. Проверить MySQL binlog.
8. Проверить Docker, если используется.
9. Настроить logrotate и правила хранения бэкапов.

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