Лог может заполнить диск VPS незаметно для владельца сайта: трафик невелик, но приложение пишет одну ошибку тысячи раз в минуту. Logrotate помогает ограничивать историю, однако неверная схема ротации способна потерять часть записей или оставить процесс пишущим в старый файл. Перед изменением нужно понять, кто пишет журнал и как он повторно открывает файл.
Фото обложки: Brian Hankins (Bhankins); Cable closet bh.jpg, Public domain. Уменьшение размеров и преобразование в WebP; кадрирование не выполнялось. Тематический снимок не изображает инфраструктуру упомянутых провайдеров.
Начните с владельца журнала
Запишите путь, приложение, пользователя, текущий размер и скорость прироста. Отличайте файловый лог от systemd journal, контейнерного stdout и удалённого сборщика. Один и тот же симптом заполненного диска требует разных инструментов. Правило logrotate для access.log не управляет автоматически журналом Docker или общей базой journald.
Уточните, не создаёт ли конфигурацию панель хостинга. Два правила для одного пути могут конфликтовать и приводить к неожиданной частоте переименования. Проверьте системный конфиг и каталог дополнительных правил до добавления нового файла. Сначала изучите действующую процедуру, затем меняйте её.
Переименование и copytruncate
| Способ | Что происходит | Риск |
|---|---|---|
| Rename + reopen | Старый файл переименован, приложение открывает новый | Без reopen процесс может писать в старый inode |
| copytruncate | Копия журнала создаётся перед обнулением активного файла | Есть окно между копированием и усечением; возможна потеря записей |
| compress | Архив сжимается после ротации | Нужны CPU, временное место и согласование с пишущим процессом |
| delaycompress | Сжатие предыдущего журнала откладывается | Не заменяет правильного повторного открытия файла |
Выбирайте поддерживаемый приложением способ. Универсальное copytruncate удобно внешне, но не гарантирует сохранность каждой записи. Для журналов, используемых в расследовании или учёте, заранее определите допустимые потери и подходящий механизм доставки.
Шаг 1. Проверьте конфигурацию без ротации
# Пример диагностики; расположение конфигурации зависит от ОС logrotate --version logrotate --debug /etc/logrotate.conf
Режим debug предназначен для чтения решений и не должен использоваться как подтверждение фактического переоткрытия лога приложением. Просмотрите ошибки путей, дубли и условия выбора. Не добавляйте force для проверки на рабочем сервере: это уже принудительная операция записи.
Сохраните состояние планировщика. В одной системе logrotate вызывается cron, в другой — timer systemd. Отсутствие файла в cron.daily не доказывает, что ротация не работает. Проверьте реально активный механизм и недавние результаты его запуска.
Шаг 2. Опишите срок и объём хранения
Запись daily задаёт период проверки ротации, а rotate — число сохраняемых выпусков. Это не всегда точное число календарных дней: влияет фактический запуск и условия size/minsize/maxsize. Посчитайте объём активного журнала, несжатых копий, сжатых архивов и запас на процедуру.
Условный пример: активный лог 400 МБ, одна свежая копия того же размера и несколько сжатых архивов могут временно потребовать заметно больше места, чем один файл. Не рассчитывайте на идеальную степень сжатия заранее. При почти полном диске сначала согласуйте безопасные действия и сохранение нужных доказательств.
Шаг 3. Проверьте создание нового файла
После переименования новый журнал должен иметь правильные владельца и режим. Ошибка create может лишить сервис права записи и скрыть дальнейшие события. Подмена проблемы широкими правами для всех пользователей нарушает границы доступа и не исправляет неверную модель владельца.
Команда postrotate зависит от приложения и его установленной версии. Не копируйте сигнал или restart из случайного примера. Найдите штатный способ reopen в документации сервиса, сохраните исходное правило и сначала проверьте его на стенде. Полный перезапуск ради ротации не всегда необходим и способен прервать активные операции.
Шаг 4. Приёмка на контрольных записях
- Подготовьте отдельный тестовый журнал с известными маркерами до ротации.
- Выполните поддерживаемую процедуру в согласованном окружении.
- Добавьте маркер после ротации через само приложение.
- Проверьте, что новая запись попала в активный файл, старая — в сохранённую историю.
- Сверьте владельца, режим и возможность чтения уполномоченным сборщиком.
- Проверьте следующий штатный запуск и отсутствие накопления лишних файлов.
Если df и du показывают разные величины, возможен удалённый файл, который процесс ещё держит открытым. Это гипотеза для проверки дескрипторов, а не причина перезапускать все службы. Найдите конкретный процесс и применимый способ закрытия файла по регламенту.
Что делать с причиной роста
Ротация управляет историей, но не устраняет ошибку приложения. Посчитайте повторяющиеся сообщения и свяжите их с релизом, заданием или конкретным запросом. Отключение всех логов ради свободного диска лишает диагностики и скрывает продолжающуюся проблему.
Не отправляйте полный журнал в публичный чат: в нём могут быть IP, параметры URL и токены. Для разбора подготовьте минимальный обезличенный фрагмент с временем и повторяемым симптомом. Срок хранения определяет владелец проекта с учётом задач эксплуатации.
FAQ
Почему после удаления лога место не освободилось?
Возможен открытый дескриптор. Проверьте конкретный процесс; удаление имени файла не обязательно завершает запись в inode.
Можно всегда использовать copytruncate?
Нет. У этого способа есть окно возможной потери записей. Выбирайте механизм по требованиям и поддержке приложения.
Debug доказывает, что ротация работает?
Он помогает проверить конфигурацию. Фактическая приёмка требует контрольных записей и проверки штатного запуска.
Вывод
Надёжная ротация сохраняет нужную историю, оставляет приложению рабочий файл и укладывается в ресурсный бюджет. Проверяйте весь цикл, а не только наличие правила в каталоге.
Для смежных задач: Заканчивается место на хостинге: диск, inode, архивы и безопасная очистка, Логи WordPress и PHP: как собрать данные для исправления ошибки, SSH и SFTP для сайта: отдельные доступы и проверка ключей.
Источник технических параметров: официальная документация. Проверено 29.10.2026. Диагностический протокол — редакционная рекомендация; команды не выполнялись на сервере HOSTIO.
При выборе самостоятельного VPS учитывайте стоимость его обслуживания. Услуги Beget — подтверждённая партнёрская ссылка HOSTIO; характеристики нужного пакета проверяются отдельно.
