Как почистить логи в 1С: журнал регистрации, файловые логи и СУБД

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

Проблема в том, что «логи» в контексте 1С — это не один файл, а минимум четыре разных хранилища: журнал регистрации самой информационной базы, технологический журнал платформы, дампы и протоколы обновлений, а также журналы СУБД, если база клиент-серверная. Чистить их нужно по-разному, и удаление «не тех» файлов может привести к потере данных или невозможности восстановить базу.

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

Какие логи есть в 1С и где они лежат

Прежде чем чистить, определите, какой именно журнал разросся. Ориентируйтесь на расположение и размер файлов.

• Журнал регистрации — события работы пользователей и ошибок. В файловой базе это каталог 1Cv8Log рядом с файлом 1Cv8.1CD. В клиент-серверной базе хранится в каталоге базы на сервере 1С (reg_1541 и аналогичные).
• Технологический журнал (ТЖ) — пишется платформой только при наличии конфигурационного файла logcfg.xml. Каталог задаётся в этом файле, обычно что-то вроде C:\Program Files\1cv8\logs или /opt/1cv8/logs.
• Логи СУБД — журнал транзакций SQL Server (.ldf), логи PostgreSQL (pg_log, WAL), журналы MS SQL error log.
• Служебные файлы — дампы аварийного завершения (.dmp), протоколы обновлений, логи агента сервера.

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

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

В том же окне настройки журнала регистрации есть смысл снизить детализацию: оставить регистрацию ошибок и предупреждений, а не «всех событий». Это замедлит рост журнала в дальнейшем. Для большинства рабочих баз достаточно уровня «Ошибки» плюс «Предупреждения» и регистрации доступа/отказа в доступе.

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

Можно ли просто удалить папку 1Cv8Log

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

Технологический журнал: отключение и ротация

Технологический журнал включается файлом logcfg.xml, который размещается в каталоге conf платформы (например, C:\Program Files\1cv8\<версия>\bin\conf). Если ТЖ был включён для диагностики и его забыли выключить, каталог логов растёт непрерывно.

Чтобы полностью отключить ТЖ, переименуйте или удалите logcfg.xml и перезапустите службы сервера 1С (для файловой базы — просто перезапустите клиенты). После этого старые файлы ТЖ можно удалить вручную — работе базы они не нужны.

Если журнал нужен постоянно, настройте ротацию прямо в logcfg.xml: параметр history в элементе <log> задаёт, сколько часов хранить файлы. Платформа сама удалит устаревшие.

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

В этом примере журнал пишется в D:\1clogs, хранится 72 часа и фиксирует только исключения (ошибки). Такой минимальный конфиг почти не влияет на производительность и не заполняет диск.

Очистка логов СУБД для клиент-серверных баз

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

SQL Server: усекновение журнала транзакций

Классическая ситуация: файл .ldf вырос в разы больше файла данных .mdf. Причина почти всегда одна — база в модели восстановления Full, а резервные копии журнала транзакций не делаются, поэтому журнал не усекается.

Если полная модель восстановления вам не нужна (для большинства баз 1С достаточно Simple, так как восстановление делается из регламентных бэкапов), переведите базу в Simple и сожмите файл журнала:

ALTER DATABASE [MyBase] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase_log', 1024);
GO

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

PostgreSQL: логи и WAL

В PostgreSQL чистятся два типа файлов: текстовые логи сервера (каталог log внутри каталога данных) и WAL-сегменты (pg_wal). Текстовые логи можно удалять вручную или настроить ротацию параметрами log_rotation_age и log_rotation_size в postgresql.conf. Каталог pg_wal вручную не трогают никогда — WAL управляется самой СУБД, и его рост означает проблему с архивированием или репликацией, которую нужно устранять, а не удалять файлы.

Что выбрать в вашей ситуации

Проверка результата и профилактика

После очистки убедитесь, что всё работает и место действительно освободилось. Затем настройте регламент, чтобы проблема не вернулась.

Для профилактики достаточно нескольких регламентных мероприятий: периодическое сокращение журнала регистрации (например, раз в квартал для активных баз), контроль свободного места на дисках сервера, ротация ТЖ через history и план обслуживания в СУБД с регулярными бэкапами. В SQL Server также полезно ограничить максимальный размер файла журнала транзакций, чтобы его рост не привёл к полному заполнению диска.

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

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