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

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

В 1С существует несколько разных «логов», и путать их нельзя. Журнал регистрации — это встроенный механизм фиксации событий (входы пользователей, изменение данных, ошибки), который хранится в файле 1Cv8.lgd в каталоге базы или в отдельном формате SQLite. Технологический журнал — текстовые дампы и лог-файлы, которые платформа пишет при включённых настройках logcfg.xml. Отдельно стоят лог-файлы СУБД (например, transaction log в MS SQL Server), которые раздуваются от интенсивной работы базы и требуют своих процедур обслуживания.

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

Какие логи есть в 1С и зачем их чистить

Прежде чем чистить, определите, какой именно лог разросся. Журнал регистрации файловой базы лежит в подкаталоге 1Cv8Log каталога базы (файл 1Cv8.lgd) или в новом формате — в виде набора файлов SQLite (1Cv8.lgd как каталог с файлами .lgp и .lgx). У клиент-серверной базы журнал хранится в каталоге srvinfo, в папке reg_1541 (или с другим портом кластера), в подкаталоге с идентификатором информационной базы.

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

Логи СУБД — отдельная история. В MS SQL Server файл журнала транзакций (.ldf) в модели восстановления Full растёт, пока не выполняется резервное копирование журнала. В PostgreSQL аналогичную роль играют WAL-файлы. Эти файлы нельзя просто удалить — их обслуживают штатными средствами СУБД.

Как уменьшить количество записываемых событий

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

Для большинства рабочих баз достаточно уровня «Ошибки» или «Ошибки, предупреждения, важная информация». Регистрацию изменения данных и доступа включайте точечно — только на период расследования или для критичных объектов, потому что именно эти события генерируют основной объём записей.

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

Как сократить журнал регистрации штатными средствами

Основной безопасный способ — команда сокращения в конфигураторе. Откройте «Администрирование» → «Журнал регистрации», затем в открывшемся окне выберите действие «Сократить» (в новых версиях платформы — через кнопку «Ещё»). Укажите дату, до которой удалять события, и обязательно отметьте сохранение сокращаемой части в файл — так вы получите архив истории в формате, который при необходимости можно открыть.

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

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

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

Что делать с файлами журнала в каталоге базы

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

В клиент-серверном варианте файлы журнала лежат в каталоге srvinfo на сервере 1С. Их нельзя трогать при работающем сервере 1С:Предприятия (агенте кластера). Если требуется полная очистка, остановите службу агента, переместите файлы журнала конкретной базы в архив, запустите службу и проверьте работу.

Никогда не чистите каталоги srvinfo целиком — там, помимо журналов регистрации, находится список информационных баз кластера и другие служебные данные. Удаление лишнего приведёт к потере регистрации баз в кластере.

Очистка технологического журнала и логов СУБД

Технологический журнал чистится простым удалением старых файлов из каталога, указанного в logcfg.xml — это обычные текстовые файлы, их удаление безопасно. Главное — после диагностики отключить или сузить настройки в logcfg.xml, иначе каталог снова заполнится. Проверьте наличие logcfg.xml в каталоге conf сервера или каталоге установки платформы.

Для MS SQL Server разросшийся .ldf-файл сокращают так: убедитесь, что настроены регулярные бэкапы журнала транзакций (модель Full), либо, если история восстановления на момент времени не нужна, переведите базу в модель Simple и выполните сжатие файла журнала через DBCC SHRINKFILE. Сжатие — разовая мера, без правильной модели восстановления файл вырастет снова.

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

В PostgreSQL следите за настройками архивирования WAL и параметром max_wal_size: скопление WAL-файлов обычно означает, что сломана архивация или репликация, и чистить файлы вручную недопустимо — нужно устранить причину.

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

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

Чтобы проблема не вернулась, настройте регулярный регламент: раз в квартал или месяц сокращайте журнал регистрации с сохранением архива, держите уровень регистрации на минимально необходимом, контролируйте свободное место на дисках сервера. Для SQL-баз обязательны регулярные бэкапы журнала транзакций — это одновременно и защита данных, и контроль размера .ldf.

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