На сервере закончилось место: как логи, кеш и бэкапы могут остановить сайт

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

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

Что чаще всего заполняет диск

• логи Nginx, Apache, PHP и приложения без ротации;
• резервные копии, которые никогда не удаляются;
• кеш и временные файлы;
• большие импорты и временные архивы;
• пользовательские загрузки;
• дампы базы, оставленные после технических работ.

Почему нужно проверять не только общий размер

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

df -h
df -i

Как быстро найти источник роста

Начинают с крупных каталогов: логи, бэкапы, /upload/, временные директории, кеш. После этого смотрят, какие файлы менялись недавно и продолжают расти. Удалять всё подряд опасно: среди крупных файлов может оказаться рабочая база, нужный архив или системный журнал.

Логи должны ротироваться

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

Бэкап может стать причиной аварии

Парадоксальная ситуация: механизм, который должен защищать проект, сам останавливает сервер. Например, ежедневный полный архив создаётся локально и никогда не очищается. Через несколько месяцев диск заполняется именно резервными копиями.

Поэтому хранение бэкапов должно быть частью стратегии: несколько локальных версий для быстрого восстановления и отдельное внешнее хранилище для истории.

Что может произойти при полном диске

• MySQL не сможет записывать новые данные;
• PHP не создаст сессию или временный файл;
• сайт перестанет принимать загрузки;
• cron-задачи начнут завершаться с ошибкой;
• логи перестанут фиксировать причину сбоя;
• обновление приложения может оборваться посередине.

Свободное место — такой же технический показатель здоровья сайта, как CPU, память и время ответа.

Как не допустить повторения

1. Настройте мониторинг свободного места и inode.
2. Включите ротацию серверных и прикладных логов.
3. Определите срок хранения локальных бэкапов.
4. Периодически проверяйте каталоги с загрузками и временными файлами.
5. Ставьте уведомления до достижения критического порога, а не после заполнения диска.

Если сайт уже нестабилен, проверку диска стоит выполнять вместе с анализом сервера, PHP и базы данных. Общая последовательность диагностики описана в статье о причинах недоступности сайта.

Мониторинг ресурсов, очистка сервера и настройка ротации могут выполняться в рамках технического сопровождения проекта.