Как очистить логи 1С: журнал регистрации и служебные файлы

Логи 1С — это прежде всего журнал регистрации, где платформа фиксирует действия пользователей, ошибки, обмены данными и системные события. В активно используемой базе он растёт постоянно: в файловом варианте журнал хранится в каталоге 1Cv8Log рядом с файлом базы, в клиент-серверном — в отдельной базе данных на сервере СУБД. Со временем файл журнала или таблица EventLog разрастается до десятков гигабайт, замедляет открытие журнала, занимает дисковое пространство и усложняет резервное копирование.

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

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

Что именно занимает место: где 1С хранит логи

Перед очисткой полезно понять, что именно растёт. В файловом варианте журнал регистрации находится в подкаталоге 1Cv8Log внутри каталога информационной базы. В старых версиях платформы это файл 1Cv8.lgf, в новых — база формата SQLite (файл 1Cv8.lgd) с сопутствующими служебными файлами. Именно этот каталог обычно и раздувается до больших размеров.

В клиент-серверном варианте журнал регистрации хранится в отдельной таблице внутри базы данных на сервере СУБД (MS SQL, PostgreSQL и др.). Его размер виден в свойствах базы средствами СУБД, а не в файловой системе сервера 1С. Очистка в этом случае выполняется либо через конфигуратор, либо штатными средствами самой СУБД.

Помимо журнала регистрации, место могут занимать и другие «логи»: технологический журнал (если он включён, его файлы лежат в каталоге, указанном в logcfg.xml), дампы аварийного завершения и временные файлы. Их очистка выполняется отдельно и не затрагивает журнал регистрации.

Подготовка: резервная копия и выгрузка истории

Любую очистку журнала начинайте с резервной копии. Для файловой базы достаточно скопировать каталог базы целиком при завершённых сеансах пользователей или выполнить выгрузку в dt через конфигуратор. Для клиент-серверной базы используйте штатное резервное копирование средствами СУБД — копирование файлов базы «вживую» недопустимо.

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

Определите глубину хранения заранее. Типичная практика — хранить события за последние 1–3 месяца в активной базе, а более старые периоды держать в выгруженных архивах. Конкретный срок зависит от требований внутреннего аудита и регламентов организации.

Сокращение журнала регистрации через конфигуратор

Штатный и самый безопасный способ — сокращение журнала через конфигуратор. Откройте базу в конфигураторе, перейдите в меню «Администрирование» → «Настройка журнала регистрации» и нажмите кнопку «Сократить». В появившемся окне укажите дату, до которой события должны быть удалены.

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

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

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

Ручная очистка журнала в файловой базе

Если журнал нужно удалить полностью или сокращение через конфигуратор неприемлемо долгое, в файловом варианте допустимо удалить каталог 1Cv8Log вручную. База при этом должна быть полностью закрыта: все сеансы пользователей и конфигуратор завершены, иначе файл журнала будет заблокирован, а база рискует получить повреждения.

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

Для старых версий платформы, где журнал хранится в формате lgf, существует альтернатива полному удалению: журнал можно периодически «разделять по периодам», задавая в настройках режим хранения (например, по месяцам), и удалять старые файлы периодов. В конфигураторе эта настройка находится там же — в окне настройки журнала регистрации.

Очистка журнала в клиент-серверной базе

В клиент-серверном варианте ручное удаление файлов не применяется — журнал живёт внутри базы данных СУБД. Основной инструмент остаётся тем же: сокращение через конфигуратор. Оно удаляет записи из таблицы журнала регистрации штатным образом и безопасно для целостности базы.

Нюанс в том, что после удаления записей физический размер файлов базы данных на диске может не уменьшиться: СУБД оставляет освобождённое место «про запас». Если нужно вернуть место файловой системе, выполните сжатие базы средствами самой СУБД (shrink) — но делайте это осознанно, поскольку частое сжатие приводит к фрагментации и падению производительности.

На больших базах рекомендуется регулярное регламентное сокращение журнала (например, раз в месяц в нерабочее время), а не разовая очистка, когда место уже кончилось. Так операция занимает минуты вместо часов и не мешает пользователям.

Технологический журнал и другие служебные логи

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

В logcfg.xml можно задать ограничение по возрасту файлов (свойство history в секции log): платформа будет автоматически удалять файлы старше заданного числа часов. Это правильный способ держать технологический журнал под контролем, не отключая его полностью.

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_logs\tjournal" history="72">
    <event><eq property="name" value="EXCP"/></event>
    <property name="all"/>
  </log>
</config>

Автоматизация и профилактика

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

Сократить объём журнала помогает и настройка уровня регистрации событий. В окне настройки журнала регистрации можно отключить запись малозначимых событий (например, информационных сообщений), оставив ошибки и важные действия. Это замедляет рост журнала без потери критичной информации.

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

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