Чистка журнала регистрации и технологических логов 1С 8.3 без потери данных

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

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

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

Под словом «логи» пользователи имеют в виду минимум четыре разных объекта. Чистят их по-разному.

Журнал регистрации

Это история событий: входы пользователей, изменение документов, ошибки, запуск регламентных заданий. Его читают при расследовании («кто удалил документ?»). Хранится в служебных файлах формата .lgf и .lgp либо в одном файле 1Cv8.lgd, если для базы выбран формат SQLite.

Не удаляйте отдельные файлы из 1Cv8Log вручную. Файл .lgf — справочник для .lgp, и рассинхрон приведёт к тому, что журнал перестанет открываться.

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

Включается вручную файлом logcfg.xml и нужен разработчикам и администраторам: замеры, блокировки, ошибки платформы. Если его включили «на пару часов» и забыли, он легко съедает диск за сутки. Это единственный лог, который можно чистить простым удалением файлов.

Кэш и временные файлы

Строго говоря, это не логи, но их часто чистят вместе. Каталоги с длинными именами вида a1b2c3d4-... в 1cv8 — это кэш конфигураций и списков баз. Удаление безопасно, но первый запуск после этого будет медленнее.

Способ 1. Сокращение журнала регистрации через Конфигуратор

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

1. Закройте у пользователей сеансы. Для клиент-серверной базы достаточно, чтобы никто не работал монопольно.
2. Откройте базу в Конфигураторе: Администрирование → Журнал регистрации.
3. Выберите команду сокращения журнала.
4. Укажите дату: все записи до неё будут удалены.
5. Отметьте сохранение удалённых записей в файл и укажите путь к нему.
6. Подтвердите. Пока идёт сокращение, лучше не открывать журнал.

Что делать, если журнал огромный

Журнал на 40-50 ГБ сокращается долго, иногда несколько часов. Платформа блокирует его на время операции. Режьте по частям: сначала до даты «год назад», затем «полгода», затем нужный срок. Каждый шаг выполняется быстрее, а при сбое вы не потеряете всю работу.

Способ 2. Чистка журнала из самой конфигурации

В типовых конфигурациях (Бухгалтерия 3.0, ЗУП 3.1, УТ 11, ERP) есть раздел администрирования с обслуживанием базы. Точное расположение зависит от релиза, поэтому ищите так: откройте Администрирование, в поле поиска по разделу введите «журнал регистрации».

Что обычно доступно:

• 📅 настройка периода хранения;
• 🧹 запуск сокращения без Конфигуратора;
• 🔒 доступ только у пользователей с правом администратора.

Если нужного пункта нет, значит ваш релиз его не содержит или у вас нет прав. Тогда используйте Конфигуратор.

Способ 3. Удаление технологических логов вручную

Сначала найдите, куда пишет журнал. Откройте logcfg.xml (по умолчанию он лежит в каталоге conf рядом с установленной платформой) и посмотрите атрибут location:

<log location="D:\1clogs" history="24">
  <event><eq property="name" value="EXCP"/></event>
  <property name="all"/>
</log>

Здесь history="24" означает «хранить файлы 24 часа». Платформа сама удаляет более старые, но только пока работает процесс, который пишет в этот каталог. Если процесс упал или конфигурацию убрали, старые файлы останутся.

Порядок действий:

1. Отключите сбор: удалите или переименуйте logcfg.xml.
2. Перезапустите службу сервера 1С или процесс, который писал логи.
3. Удалите содержимое каталога location или файлы старше нужного срока.
4. Верните logcfg.xml с разумным history, если сбор ещё нужен.

Способ 4. Автоматическая очистка по расписанию

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

Windows: bat-файл и планировщик заданий

Удаляем файлы старше 7 дней:

@echo off
forfiles /p "D:\1clogs" /s /m *.log /d -7 /c "cmd /c del @path"

Параметр /d -7 — возраст в днях, /s — обход вложенных папок. Запустите сначала с echo вместо del, чтобы увидеть, что будет удалено.

Добавьте задание: Планировщик заданий → Создать задачу → триггер «Ежедневно» → действие «Запуск программы» с путём к bat.

Linux: find и cron

find /var/log/1c -type f -name "*.log" -mtime +7 -delete

Строка для crontab -e, запуск каждую ночь в 3:30:

30 3 * * * find /var/log/1c -type f -name "*.log" -mtime +7 -delete

Очистка кэша клиента

Закройте 1С и удалите содержимое двух каталогов:

rd /s /q "%LOCALAPPDATA%\1C\1cv8"
rd /s /q "%APPDATA%\1C\1cv8"

Список баз при этом сохраняется в файле ibases.v8i (обычно в %APPDATA%\1C\1CEStart), на него команда не влияет. Но если вы используете нестандартные настройки окон, их придётся задать заново.

Журнал транзакций СУБД: отдельная история

Если в клиент-серверной версии разрастается не 1С, а сама СУБД, причина в журнале транзакций.

• MS SQL Server. Файл .ldf растёт, когда база в модели восстановления «Полная», а резервные копии журнала не делаются. Решение: настроить регулярный бэкап журнала транзакций, после чего при необходимости один раз сжать файл. Переключение на «Простую» модель освободит место, но лишит вас восстановления на момент сбоя.
• PostgreSQL. Растёт каталог WAL, если архивация или репликация не успевает его забирать. Править каталог руками нельзя, это приведёт к порче кластера.

Эти операции выполняет администратор СУБД. Из 1С журнал транзакций не чистится.

Как сделать так, чтобы логи не разрастались снова

Очистка без настройки лечит симптом. Три параметра решают проблему.

Срок хранения и период разделения

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

Уровень детализации

Не включайте событие «Данные.Чтение» и подобные подробные события без причины: на базе с сотней пользователей это сотни тысяч записей в день. Для обычной работы достаточно входа, изменений данных и ошибок.

Ограничение технологического журнала

Всегда указывайте в logcfg.xml атрибут history, а в event фильтруйте нужные события. Конструкция <property name="all"/> без фильтра по событиям пишет всё, что может.

Где искать журнал в клиент-серверной базе

В клиент-серверном варианте журнал лежит не рядом с базой, а в служебном каталоге сервера 1С (srvinfo). Внутри — папки вида reg_1541, а в них подкаталоги с идентификаторами баз.

Чтобы не гадать, какая папка чья:

1. Откройте консоль администрирования кластера серверов.
2. Найдите нужную информационную базу и посмотрите её идентификатор.
3. Сопоставьте его с именем подкаталога в srvinfo.

Сразу видно, какая база тянет больше всего. Нередко выясняется, что 80% места занимает одна тестовая копия, про которую все забыли.

Формат журнала: lgf/lgp или lgd

Платформа 8.3 умеет хранить журнал в двух форматах:

• 📁 Файлы .lgf и .lgp — классический формат, много небольших файлов. Удобно сокращать по периодам.
• 🗄 Один файл 1Cv8.lgd (SQLite) — компактнее, быстрее отбор, но один большой файл сложнее копировать на ходу.

Сменить формат можно в Конфигураторе, в параметрах журнала регистрации. Старые записи при этом остаются в прежнем формате, поэтому после смены перенос и сокращение лучше планировать заранее.

Сколько места освобождается: прикинем заранее

Простой расчёт помогает понять, стоит ли возиться. Допустим, в базе работают 30 человек, каждый создаёт примерно 400 записей журнала в день (вход, чтение настроек, запись документов).

• 30 × 400 = 12 000 записей в сутки;
• за 250 рабочих дней — около 3 млн записей;
• при среднем размере записи около 1 КБ это порядка 3 ГБ в год.

Если в журнал попали подробные события чтения данных, цифра вырастает в 10-20 раз. Именно так появляются журналы в 40-50 ГБ. Поэтому сначала проверьте, какие события включены, и только потом чистите.

Проверка после чистки

Через день после очистки сделайте короткий контроль:

• ✅ журнал регистрации открывается, свежие события на месте;
• ✅ отбор по пользователю и по дате работает без долгих задержек;
• ✅ регламентные задания и резервное копирование отработали без ошибок;
• ✅ свободное место на диске вернулось к ожидаемому значению.

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

Типичные ошибки при чистке

• ❌ Удалили 1Cv8Log целиком вместе с базой. В файловой базе рядом лежит 1Cv8.1CD: ошибиться в пути проще, чем кажется. Проверяйте, что находитесь именно в папке журнала.
• ❌ Чистили журнал при работающих пользователях. Часть записей ещё пишется, операция затягивается или падает.
• ❌ Удалили свежие файлы технологического журнала, а нужно было разобрать недавнюю ошибку. Сначала скопируйте нужные, потом чистите.
• ❌ Скрипт del без проверки пути. Опечатка в переменной, и под удаление попадают чужие каталоги. Тестируйте с echo.
• ❌ Ожидали, что место на диске освободится сразу. После сокращения файловой базы размер 1Cv8.1CD не уменьшается, пока вы не выполните выгрузку и загрузку информационной базы.

Ответ на «а можно ничего не чистить?»

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

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