В современной IT-инфраструктуре файлы журналов (логи) — это «черный ящик» любого сервера или приложения․ Они фиксируют ошибки, события безопасности, запросы пользователей и состояние оборудования․ Однако без должного контроля логи способны заполнить весь дисковый раздел, приведя к остановке сервисов и потере критически важных данных․ Статья подробно рассматривает механизмы ротации логов (log rotation), настройку утилиты logrotate, стратегии архивации и резервного копирования, актуальные на ․

Почему необходима ротация логов?

Ротация журналов (log rotation) — это процесс управления жизненным циклом лог-файлов: копирование, очистка, архивация (сжатие), удаление устаревших архивов и сигнализация процессам о необходимости переоткрыть файлы для записи․

• Предотвращение переполнения диска: Без ротации логи разрастаются до неприличных размеров, занимая всё свободное место на разделе /var/log․
• Производительность: Огромные текстовые файлы сложны для анализа (grep, less, SIEM-системы) и замедляют запись новых событий․
• Соответствие политикам безопасности: Многие стандарты (PCI DSS, GDPR, 152-ФЗ) требуют хранения логов определенное время (от 6 месяцев до 3 лет) с гарантированной целостностью․
• Управление дисковым пространством: Позволяет предсказуемо планировать емкость хранилищ․

Ключевая утилита: logrotate

В экосистеме Linux (включая РЕД ОС, Debian, CentOS, Ubuntu) де-факто стандартом является утилита logrotate․ Она автоматизирует рутину: сжатие, удаление старых файлов, отправку по почте и запуск пользовательских скриптов после ротации․

Основной конфигурационный файл

Глобальные настройки обычно находятся в /etc/logrotate․conf․ В РЕД ОС и большинстве дистрибутивов он подключает фрагменты конфигурации из директории /etc/logrotate․d/․

Пример глобального конфига /etc/logrotate․conf:

# Глобальные настройки по умолчанию
weekly
rotate 4
create
compress
include /etc/logrotate․d

/var/log/wtmp {
 monthly
 create 0664 root utmp
 minsize 1M
 rotate 1
}

/var/log/btmp {
 missingok
 monthly
 create 0600 root utmp
 rotate 1
}

Структура директории /etc/logrotate․d/

Рекомендуемая практика — не редактировать основной logrotate․conf под конкретные сервисы, а создавать отдельные файлы в /etc/logrotate․d/․ Это упрощает управление пакетами (обновления не затрют ваши настройки) и поддерживает чистоту конфигурации․

cd /etc/logrotate․d/

touch nginx
touch cisco

Детальный разбор директив конфигурации

Понимание директив — ключ к гибкой настройке․ Ниже приведены основные группы параметров․

Основные настройки расписания и хранения

• daily / weekly / monthly / yearly — частота ротации․
• rotate N — количество хранимых архивов․ Старые удаляются․ rotate 0 — удалять сразу после ротации․
• size N / minsize N / maxsize N, ротация по размеру (например, size 100M)․ Срабатывает при запуске, если файл превысил лимит․ minsize гарантирует, что ротация не произойдет, если файл меньше заданного размера, даже если наступил срок (daily/weekly)․
• maxage N, удалять архивы старше N дней, независимо от количества (rotate)․

Обработка файлов и сжатие

• compress — сжимать архивы (по умолчанию gzip)․
• compresscmd / compressext / compressoptions — использовать другой компрессор (например, xz или zstd для лучшего соотношения сжатия/скорости)․
• delaycompress — отложить сжатие на следующий цикл ротации․ Полезно, если процесс все еще пишет в старый файл (до отправки сигнала релоада)․
• create [mode] [owner] [group] — создать новый пустой файл после ротации с заданными правами (важно для сервисов, не умеющих релоадить логи сами)․
• nocreate — не создавать новый файл (сервис должен сделать это сам)․
• copytruncate — скопировать содержимое в архив и обнулить исходный файл (: > file)․ Критично: Небольшое окно потери логов между копированием и обнулением․ Использовать только если сервис не поддерживает релоад (SIGHUP) и не может писать в новый файл․
• missingok — не выдавать ошибку, если лог-файл отсутствует․
• notifempty — не ротировать пустые файлы․

Именование и размещение архивов

• dateext — добавлять дату к имени архива (формат -YYYYMMDD) вместо номера (․1, ․2)․ Удобно для сортировки и поиска․
• dateformat — кастомный формат даты (strftime), например -%Y-%m-%d_%H-%M․
• olddir /path/to/archive — перемещать архивы в отдельную директорию (на другом диске/томе)․ Директория должна существовать и иметь права на запись․
• noolddir — хранить архивы в той же директории (по умолчанию)․

Скрипты и хуки (Pre/Postrotate)

Позволяют выполнять команды до/после ротации․ Обязательно оборачиваются в блоки sharedscripts (выполнить один раз для всех файлов, подходящих под маску) или nosharedscripts (по умолчанию, для каждого файла)․

sharedscripts
postrotate
 # Отправляем сигнал SIGHUP системному логгеру (rsyslog/syslog-ng)
 /bin/kill -HUP `cat /var/run/syslogd․pid 2>/dev/null` 2>/dev/null || true
 # Или для systemd сервисов:
 # systemctl reload nginx > /dev/null 2>&1 || true
endscript

• prerotate ․․․ endscript — команды перед ротацией (например, флаш буферов БД)․
• postrotate ․․․ endscript — команды после (релоад сервиса)․
• sharedscripts, запускать скрипт один раз за запуск logrotate, а не для каждого файла․
• true в конце, гарантирует код возврата 0, чтобы ошибка в скрипте не прервала ротацию остальных файлов․

Практические примеры конфигурации

Nginx (Высокая нагрузка, ежедневно, с датой)

Файл: /etc/logrotate․d/nginx

/var/log/nginx/*;log {
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
 create 640 root adm
 sharedscripts
 dateext
 dateformat -%Y-%m-%d
 olddir /var/log/nginx/archive
 postrotate
 [ -f /var/run/nginx․pid ] && kill -USR1 `cat /var/run/nginx․pid`
 endscript
}

Прием удаленных логов (Syslog/Rsyslog от сетевого оборудования Cisco)

Файл: /etc/logrotate․d/cisco․ Логи пишутся в /var/log/remote/ с именами хостов․

/var/log/remote/*․log {
 daily
 rotate 10
 missingok
 notifempty
 compress
 size 1M
 sharedscripts
 postrotate
 /bin/kill -HUP `cat /var/run/syslogd․pid 2>/dev/null` 2>/dev/null || true
 endscript
}

Важно: Маска *․log обработает каждый файл отдельно․ sharedscripts гарантирует, что syslog получит только один SIGHUP за запуск․

Приложения, не поддерживающие релоад (copytruncate)

Файл: /etc/logrotate․d/legacy-app

/var/log/legacy/app․log {
 daily
 rotate 7
 compress
 missingok
 notifempty
 copytruncate
 # create не нужен, copytruncate обнуляет исходный файл
}

Запуск, отладка и автоматизация

Автоматический запуск (Cron / Systemd Timer)

Обычно устанавливается пакетом․ Проверьте:

• /etc/cron․daily/logrotate — классический запуск раз в сутки (обычно в 06:25 через anacron)․
• /usr/lib/systemd/system/logrotate․timer — в системах с systemd․

Пример ручной записи в /etc/crontab (если нужен специфический стейт-файл):

# Формат: /opt/sbin/logrotate -s <файл_состояния> <файл_настроек>
0 1 * * * root /opt/sbin/logrotate -s /HOME/logs/logrotate․state /HOME/etc/logrotate․conf

Параметр -s (state file) критически важен при запуске нескольких экземпляров logrotate с разными конфигами (например, для разных пользователей или контейнеров), чтобы они не конфликтовали по счетчикам ротации․

Ручной запуск и проверка

• logrotate -d /etc/logrotate․conf, Debug (dry-run)․ Показывает, что было бы сделано, не меняя файлы и не обновляя state-файл․ Главный инструмент отладки․
• logrotate -f /etc/logrotate․conf — Force․ Принудительная ротация игнорируя расписание и размер․ Полезно сразу после правки конфига․
• logrotate -v /etc/logrotate․conf, Verbose․ Подробный вывод реальных действий․

Файл состояния (logrotate․status)

Хранит дату последней ротации для каждого файла․ По умолчанию /var/lib/logrotate/status или /var/log/logrotate․status․ Не редактируйте вручную, если не понимаете последствия (сброс дат вызовет немедленную ротацию)․

Архивация в облако / S3 (Долгосрочное хранение)

Локальная ротация решает проблему диска, но не проблему сохранности при сбое сервера․ Для соответствия требованиям хранения (1-3 года) архивы нужно выгружать в объектное хранилище (S3, MinIO, Yandex Object Storage, S3cmd/rclone)․

Интеграция через скрипты (postrotate)

/var/log/nginx/*․log {
 ․․․
 postrotate
 # Пример синхронизации архивов в S3 после ротации
 # Запускаем в фоне, чтобы не блокировать ротацию
 ( rclone move /var/log/nginx/archive/ s3:my-bucket/nginx-logs/$(hostname)/ --min-age 1d >/dev/null 2>&1 ) &
 endscript
}

Важный нюанс S3cmd / rclone

При использовании s3cmd sync или rclone для загрузки директории с логами, следите за слешами․ Ошибка: s3cmd sync /var/log/syslog s3://bucket/ загрузит файл․ Правильно для директории: s3cmd sync /var/log/syslog/ s3://bucket/syslog/․ Без слеша в конце источника утилита может воспринять путь как один файл, а не каталог․

Стратегия хранения: RAID != Backup (Критически важно!)

Информация из практики администрирования хранилищ логов:

Организация хранилища (NAS/DAS)

Если в корпусе сервера нет мест под диски — используйте NAS (Network Attached Storage) или DAS (Direct Attached Storage)․

• Монтируйте сетевую шарку (NFS/CIFS) в /var/log/archive или используйте olddir в logrotate․
• Для горячей замены дисков используйте корпуса с Hot-swap и файловую систему, устойчивую к ошибкам (ZFS, Btrfs, XFS/ext4 с LVM)․
• Настройте ПО (rsync, rclone, Veeam Agent, BorgBackup), которое активно копирует активные логи на резервный накопитель (например, ночью)․

Ротация резервных дисков (Offline/Offsite)

Если бэкап уходит на съемные HDD (RDX, USB-корпуса):

1. Имейте набор дисков (минимум 3: Один в сервере, Один в сейфе/другом здании, Один в пути)․
2. ПО бэкапа должно обновлять старый диск при ротации (инкрементально или полно)․
3. Проверяйте восстановление (restore test) раз в квартал․

Расчет объема и планирование емкости

Для оптимальной настройки rotate N и size M нужно знать скорость накопления логов․

Формула:

Необходимое место ≈ (Средний объем логов в день × Дней хранения) × 1․5 (запас на пики + метаданные FS)

Пример расчета для Nginx:

• RPS: 500 запросов/сек․
• Средняя строка лога: ~500 байт․
• В сутки: 500 * 500 * 86400 ≈ 21․6 GB/день (raw)․
• Сжатие (gzip/xz): ~10-15% от raw → ~2․5 ⎻ 3 GB/день․
• Хранение 30 дней: ~90 GB․
• С запасом 1․5x: нужно ~135-150 GB на диске /var/log или olddir․

Настройка: daily, rotate 30, compress, maxsize 5G (страховка от всплесков)․

Лучшие практики (Best Practices) -026

1. Централизованный сбор: Не храните логи только локально․ Используйте Vector, Fluent Bit, Filebeat, Promtail (Loki) для отправки в SIEM (Elastic, Splunk, ClickHouse, Loki, VictoriaLogs)․ Локальная ротация — это «последняя линия обороны» до ухода в централизованное хранилище․
2. Структурированные логи (JSON): Настройте приложения на вывод JSON․ Это упрощает парсинг и экономит место при сжатии (повторяющиеся ключи сжимаются отлично)․
3. Используйте Zstd вместо Gzip: compresscmd /usr/bin/zstd, compressext ․zst, compressoptions -3 -T0․ Zstd сжимает в 2-3 раза быстрее gzip при лучшем или сопоставимом коэффициенте․
4. Мониторинг logrotate: Добавьте проверку в Zabbix/Prometheus/Node Exporter:
   • Размер директории /var/log․
   • Код возврата последнего запуска logrotate (через systemctl status logrotate или парсинг логов cron)․
   • Возраст самых старых файлов (алерт, если лог не ротируется > 2 дней)․
5. Права доступа: Логи часто содержат PII (IP, email, токены)․ Ставьте create 640 root adm или 600․ Ограничьте доступ к olddir․
6. Immutable флаг (chattr +i): Для аудита критичных логов (auditd, auth․log) можно после ротации ставить атрибут неизменяемости на архив (chattr +i /var/log/audit/audit․log-20260901․gz), но это усложняет удаление по rotate (нужен prerotate скрипт со chattr -i)․

Чек-лист развертывания на новом сервере

• [ ] Установлен logrotate, cron/systemd-timers․
• [ ] Созданы конфиги в /etc/logrotate․d/ для всех сервисов (nginx, postgres, docker, app, syslog)․
• [ ] Настроен compress + delaycompress + dateext․
• [ ] Настроен olddir на отдельный том/раздел (или NAS)․
• [ ] Настроены postrotate скрипты для релоада сервисов (systemctl reload / kill -HUP / kill -USR1)․
• [ ] Протестировано: logrotate -d /etc/logrotate․conf (нет ошибок)․
• [ ] Принудительно запущено: logrotate -fv /etc/logrotate․conf (файлы созданы, сервисы переоткрыли дескрипторы)․
• [ ] Настроена выгрузка архивов в S3 / Backup-сервер (rclone/s3cmd/borg)․
• [ ] Настроен мониторинг свободного места на /var/log и статуса cron-job․
• [ ] Документирована процедура восстановления логов из бэкапа/облака․

Грамотная настройка архива логов — это не просто про экономию места на диске․ Это фундамент наблюдаемости (Observability), безопасности (SecOps) и соответствия требованиям регуляторов (Compliance)․ Использование logrotate с правильными директивами (dateext, compress, sharedscripts, olddir), сочетание локальной ротации с централизованным сбором (Loki/ELK) и обязательное наличие независимого резервного копирования (Off-site/Cloud) — стандарт надежной инфраструктуры на 2026 год․

Помните: RAID — это доступность, Backup — это выживаемость․ Настройте оба слоя․