Очистка журналов 1С на сервере: что удалять, а что трогать нельзя

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

Начните с замера. Часто диск съедает не журнал регистрации, а технологический журнал, который кто-то включил для отладки и забыл. Поэтому сначала выясните, где лежат гигабайты, и только потом выбирайте способ очистки логов 1С 8.3 на сервере.

Что лежит на сервере и где искать лишние гигабайты

На сервере 1С живут четыре типа «логов». Путать их нельзя: чистятся они по-разному.

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

Windows (PowerShell):

Get-ChildItem "D:\1c\srvinfo" -Directory -Recurse -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -in '1Cv8Log','1Cv8Reg' } |
  ForEach-Object {
    $size = (Get-ChildItem $_.FullName -Recurse -File | Measure-Object Length -Sum).Sum
    "{0,8:N0} МБ  {1}" -f ($size/1MB), $_.FullName
  }

Linux:

du -h --max-depth=3 /home/usr1cv8/.1cv8 2>/dev/null | sort -rh | head -20
df -h /home /var

Пути в примерах замените на свои: каталог кластера задаётся при установке сервера 1С, и у каждого администратора он свой.

Как почистить журнал регистрации 1С 8.3 средствами платформы

Журнал регистрации хранит историю действий пользователей: входы, изменения данных, ошибки, фоновые задания. Удалять его файлы руками в серверной базе нельзя. Каталог привязан к базе, а в файловом формате 1Cv8.lgd это ещё и SQLite-файл, который платформа держит открытым.

Штатный путь такой:

1. Запустите конфигуратор под учётной записью с правами администратора базы. Лучше в тот момент, когда пользователи не работают.
2. Откройте меню «Администрирование» и найдите пункт «Журнал регистрации». Внутри есть команда сокращения журнала.
3. Выберите, до какой даты сохранить записи. Всё, что старше, будет удалено.
4. Подтвердите действие и дождитесь окончания. На большом журнале операция идёт десятки минут.

То же делается из режима «1С:Предприятие»: у пользователей с административными правами в разделе администрирования есть настройки журнала регистрации. Названия пунктов в разных конфигурациях немного отличаются, поэтому, если не нашли команду, откройте журнал регистрации и посмотрите команды в его верхней панели.

Перед сокращением сделайте копию базы . Операция необратима: удалённые записи не вернуть.

Настройте сокращение так, чтобы чистка шла сама

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

• 🟢 Небольшая база, до 20 пользователей: хранить 3–6 месяцев.
• 🟡 Средняя база, активная работа, обмены: 1–2 месяца.
• 🔴 Нагруженная база с интенсивными фоновыми заданиями: 2–4 недели, и отдельно отключить запись ненужных событий.

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

Файловая база: можно ли просто удалить каталог 1Cv8Log

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

Порядок такой:

1. Убедитесь, что в базе никто не работает, и закройте её во всех сеансах. Проверьте процессы 1cv8 в диспетчере задач или командой ps aux | grep 1cv8.
2. Скопируйте весь каталог базы в безопасное место. Копия нужна не из паранойи: файл 1Cv8.1CD лежит рядом с логами.
3. Переименуйте каталог 1Cv8Log в 1Cv8Log_old, не удаляйте сразу.
4. Запустите базу. Платформа создаст журнал заново.
5. Через неделю, если всё работает, удалите переименованный каталог.

Такой приём удобен для старых файловых баз, где журнал разросся до размеров, сопоставимых с самой базой. Для клиент-серверных баз он не подходит: каталог журнала там привязан к кластеру и управляется службой сервера.

Технологический журнал 1С: как ограничить и очистить

Технологический журнал включается файлом logcfg.xml и пишет подробности работы платформы: вызовы, блокировки, исключения, медленные запросы. Он растёт быстрее всего. Одна неудачная настройка, и за сутки получаются десятки гигабайт.

Файл logcfg.xml лежит в каталоге conf рядом с установленной платформой. На Windows это обычно подпапка conf в каталоге установки 1cv8, на Linux в каталоге платформы под /opt/1cv8. Платформа перечитывает файл при изменении, перезапуск сервера не нужен.

Минимальный пример с автоматическим удалением старых данных:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c\tj" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Параметр history задаёт, сколько часов хранить файлы. Через 24 часа платформа сама удаляет старые данные этого лога. Если его не задать, ТЖ копится вечно.

Что делать, когда ТЖ уже разросся:

1. Откройте logcfg.xml и поставьте нужное значение history или отключите ненужный <log>, закомментировав блок.
2. Если сбор вам не нужен вообще, переименуйте файл, например в logcfg.xml.off. Запись остановится.
3. Подождите минуту-две и удалите каталоги с данными ТЖ. Они разложены по подпапкам по имени процесса и дате: rphost_12345, внутри файлы вида 26100713.log.
4. Если файлы заняты процессом, удалить их не получится. Остановите сбор и повторите.

Какой период хранения выбрать для ТЖ

• ⏱ Поиск конкретной проблемы: 1–6 часов, потом выключить.
• 📊 Постоянный мониторинг блокировок и исключений: 24–72 часа.
• 🔍 Разбор инцидента задним числом: заранее выделенный отдельный диск и срок не более недели.

Автоматическая очистка на Linux: logrotate и find

На Linux удобнее всего связка из find по расписанию и, при необходимости, logrotate. Для каталога ТЖ и дампов подойдёт простая команда.

Проверьте сначала, что именно будет удалено:

find /var/log/1c-tj -type f -name '*.log' -mtime +3 -print

Если список правильный, замените -print на -delete:

find /var/log/1c-tj -type f -name '*.log' -mtime +3 -delete
find /var/log/1c-tj -mindepth 1 -type d -empty -delete

Первая команда удаляет файлы старше трёх суток, вторая убирает пустые папки процессов.

Поставьте задание в cron на ночь, под пользователем, от имени которого работает сервер 1С (обычно usr1cv8):

# crontab -u usr1cv8 -e
30 3 * * * find /var/log/1c-tj -type f -name '*.log' -mtime +3 -delete

Для файлов, которые пишутся одним потоком (например, свои логи интеграций), подходит logrotate:

/var/log/1c-integration/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

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

Скрипты очистки для Windows и Linux

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

PowerShell для Windows Server

$path    = 'D:\1c\tj'
$days    = 3
$limit   = (Get-Date).AddDays(-$days)
$log     = 'D:\1c\clean.log'

$old = Get-ChildItem $path -Recurse -File -ErrorAction SilentlyContinue |
       Where-Object { $_.LastWriteTime -lt $limit }

$freed = ($old | Measure-Object Length -Sum).Sum
$old | Remove-Item -Force -ErrorAction SilentlyContinue

Get-ChildItem $path -Recurse -Directory |
  Where-Object { -not (Get-ChildItem $_.FullName -Force) } |
  Remove-Item -Force -ErrorAction SilentlyContinue

"{0}  удалено {1:N0} МБ" -f (Get-Date -Format s), ($freed/1MB) | Add-Content $log

Запускайте через «Планировщик заданий» Windows от имени учётной записи, у которой есть права на этот каталог. Активные файлы будут пропущены: ErrorAction SilentlyContinue не даст скрипту упасть.

Bash для Linux

#!/usr/bin/env bash
set -euo pipefail

DIR="/var/log/1c-tj"
DAYS=3
LOG="/var/log/1c-clean.log"

[ -d "$DIR" ] || { echo "нет каталога $DIR" >&2; exit 1; }

before=$(du -sm "$DIR" | cut -f1)
find "$DIR" -type f -mtime +"$DAYS" -delete
find "$DIR" -mindepth 1 -type d -empty -delete
after=$(du -sm "$DIR" | cut -f1)

echo "$(date -Is) было ${before} МБ, стало ${after} МБ" >> "$LOG"

Проверка [ -d "$DIR" ] защищает от опечатки в пути. Добавьте в скрипт отправку уведомления, если свободного места меньше порога, и вы узнаете о проблеме до того, как остановятся сеансы.

Для проверки порога удобно взять простое условие:

free=$(df --output=pcent /var | tail -1 | tr -dc '0-9')
[ "$free" -gt 85 ] && echo "Диск /var заполнен на ${free}%"

Что делать, если диск уже забит и сервер встал

Когда свободного места нет совсем, 1С может не стартовать, а сеансы падают с ошибками записи. Действуйте по порядку, от безопасного к рискованному.

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

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

Одноразовая чистка решает проблему на пару месяцев. Чтобы она не вернулась, настройте три вещи.

• 🗓 Срок хранения. Для журнала регистрации задайте автоматическое сокращение, для ТЖ history в logcfg.xml.
• 📉 Объём записи. Отключите события и уровни, которые никто не читает. Особенно шумят фоновые задания и обмены.
• 🔔 Мониторинг диска. Уведомление на 80–85% заполнения. Хватает простого задания, которое пишет в чат или на почту.

Отдельно стоит вынести ТЖ и дампы на отдельный диск или раздел. Тогда переполнение логов не остановит работу баз, а в худшем случае прекратится только запись диагностики.

Частые вопросы