Как чистить логи 1С без потери данных

Логи 1С — это журнал регистрации (файл 1Cv8.lgd в папке базы) и технологический журнал (текстовые файлы, которые платформа пишет по настройке logcfg.xml). Со временем они разрастаются до десятков гигабайт: база начинает медленнее открываться, резервные копии занимают всё больше места, а диск сервера рискует переполниться в самый неподходящий момент.

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

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

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

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

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

Отдельно стоит упомянуть логи СУБД для клиент-серверного варианта: журнал транзакций MS SQL или PostgreSQL. Они не относятся к логам 1С напрямую, но тоже растут и требуют своей регламентной обрезки средствами самой СУБД — например, через модель восстановления Simple и план обслуживания.

Когда чистить логи, а когда лучше подождать

Чистка оправдана, когда файл журнала регистрации заметно влияет на работу: база долго открывается, резервная копия файловой базы копируется непозволительно долго, диск заполнен. Ориентировочный сигнал — 1Cv8.lgd размером в несколько гигабайт при активной работе десятков пользователей.

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

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

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

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

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

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

Как настроить автоматическое хранение журнала

Чтобы не чистить журнал вручную, настройте автоматическое сокращение. В свойствах информационной базы (Конфигуратор → Администрирование → Параметры информационной базы, либо через консоль кластера для серверного варианта) можно задать режим хранения событий: не сокращать, сокращать по достижении определённого периода.

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

Как очистить технологический журнал

Технологический журнал включается файлом logcfg.xml, который размещают в каталоге conf сервера 1С или в каталоге версии платформы. Если журнал включён, он может генерировать гигабайты текстовых файлов в день, особенно при сборе запросов и блокировок. Каталог с логами задаётся параметром <log location="...">.

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

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

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

Частые ошибки при чистке логов

Самая распространённая ошибка — удаление 1Cv8.lgd файловым менеджером вместо штатного сокращения. Второе место занимает чистка без бэкапа: если во время сокращения пропадёт питание или произойдёт сбой, база может остаться в повреждённом состоянии, и восстанавливаться придётся именно из копии.

Ещё одна ошибка — ожидание, что сокращение журнала ускорит саму работу с документами. Журнал регистрации влияет в основном на открытие базы, резервное копирование и работу самого журнала. Если медленно проводятся документы, причину нужно искать в индексах, блокировках и запросах, а не в размере логов.

Как проверить результат чистки

После сокращения журнала откройте его в конфигураторе и убедитесь, что самое старое событие соответствует заданной дате. Проверьте размер файла 1Cv8.lgd или таблицы EventLog — он должен уменьшиться соразмерно удалённому периоду. Запустите базу в пользовательском режиме и убедитесь, что вход и работа проходят без ошибок.

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

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