Журнал регистрации 1С разросся до сотни гигабайт: что делать

Журнал регистрации 1С разрастается из-за долгого срока хранения событий, работы через веб-сервисы и постоянных обменов с сайтом или маркетплейсами — файлы .lgf/.lgp или таблицы в СУБД занимают десятки гигабайт и забивают диск сервера. Решение: сократить период хранения в конфигураторе, перенести журнал в отдельную базу и настроить регулярную очистку, а на растущих компаниях — вынести хранение на отдельный сервер с запасом по диску.

журнал регистрации 1С: что пишет и куда девается место на диске

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

Данные попадают либо в файлы .lgf и .lgp на диске сервера, либо в отдельные таблицы СУБД, если журнал настроен на хранение в базе данных. Оба варианта растут пропорционально числу пользователей и интенсивности работы — чем активнее компания использует 1С, тем быстрее журнал съедает свободное место. Разросшийся журнал заодно утяжеляет резервные копии: бэкап базы копирует и его, поэтому ночное копирование, которое раньше укладывалось в час, начинает занимать заметно больше времени и места в хранилище.

Настройки, которые устраивали базу на 10 пользователей, через год-два при штате в 40-50 человек уже не годятся: тот же период хранения «навсегда» на выросшей базе даёт совсем другой объём файлов. Компания меняет тарифный план, подключает новые обмены, добавляет сотрудников — а параметры журнала остаются теми же, что задавались при внедрении.

почему возникает разрастание журнала регистрации

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

Причина обычно не одна, а сочетание нескольких:

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

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

Пока журнал растёт незаметно, кажется, что это не срочно. Но когда диск заканчивается полностью, СУБД перестаёт писать новые данные, и база 1С останавливается прямо посреди рабочего дня. Бухгалтерия не проводит документы, склад не отгружает заказы, отчёт в налоговую откладывается до восстановления сервера — а экстренная чистка боевой базы под давлением времени рискованнее плановой в разы.

как исправить: чистим и сжимаем журнал регистрации

через конфигуратор

Штатный способ — зайти в конфигуратор, открыть «Администрирование» → «Журнал регистрации» и задать период, за который данные нужно сохранить: например, три месяца вместо «хранить всегда». Платформа отбросит записи старше указанной даты и физически уменьшит файлы .lgf/.lgp или таблицы в СУБД. Перед сокращением стоит выгрузить архивную копию, если данные нужны для внутреннего аудита или разбирательств.

через консоль администрирования кластера

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

через отдельную базу журнала

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

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

что делать, если ошибка повторяется после чистки

Сократили период хранения, освободили место — а через пару недель диск снова забит. Это значит, что почищен симптом, а не причина. Порядок диагностики простой:

1. ✓открыть журнал и отфильтровать события за последние сутки по источнику и виду события;
2. ✓проверить, какое регламентное задание или обмен формирует основную массу записей;
3. ✓посмотреть, не завершается ли это задание постоянно с ошибкой — тогда оно логирует один и тот же сбой снова и снова;
4. ✓сверить объём диска до и после устранения найденной причины, а не полагаться на визуальную оценку.

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

как предотвратить повторное разрастание журнала

Разовая чистка снимает симптом на пару месяцев, но без регламента проблема возвращается. Что стоит настроить один раз и не вспоминать:

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

Полезно закрепить эту рутину за конкретным человеком с датой в календаре, а не оставлять «на потом»: журнал, который проверяют раз в месяц по чек-листу, не доводит до аварийной остановки базы. Отключать журнал совсем — плохая идея даже при нехватке места: он остаётся источником данных о том, кто и когда работал с информацией, включая персональные данные сотрудников и клиентов, а требования к учёту такого доступа задаёт 152-ФЗ. Разумнее сокращать хранение до нужного минимума, а не убирать журнал целиком.

сколько стоит держать журнал под контролем

Настройка регламента и перенос журнала на отдельный ресурс — разовая работа для сисадмина или специалиста по 1С, дальше система работает по расписанию сама. Если своего системного администратора в штате нет, сопровождение 1С и системное администрирование обходится от 3800 руб/час — обычно на настройку журнала и автоматической очистки уходит одна-две сессии.

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

Небольшой компании с базой на 5-10 пользователей часто хватает переноса на виртуальный сервер для 1С с чуть большим диском — этого достаточно, чтобы журнал не создавал проблем ещё пару лет вперёд. Для компаний, которые уже упёрлись в лимиты собственного сервера, аренда сервера 1С с тарифом от 1 100 ₽/мес за пользователя закрывает вопрос сразу: диск подбирается под реальный объём базы и журнала, а не под то, что было куплено три года назад. Быстрое хранилище на арендованном сервере заодно сокращает время резервного копирования — бэкап разросшегося журнала перестаёт быть узким местом ночного расписания. Для тяжёлых конфигураций вроде ERP, где журнал регистрации растёт особенно быстро из-за объёма документооборота, отдельный сервер под 1С:ERP с расширенным диском снимает эту нагрузку заранее, а не после первого падения базы.

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

Что будет, если не чистить журнал регистрации 1С?

Диск сервера постепенно заполняется файлами журнала, и когда свободного места не остаётся, СУБД перестаёт записывать новые данные — база 1С останавливается прямо во время работы. Пользователи не могут провести документы, склад не отгружает заказы, а восстановление сервера в аварийном режиме занимает больше времени, чем плановая чистка.

Как часто нужно чистить журнал регистрации в 1С?

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

Можно ли полностью отключить журнал регистрации?

Технически можно, но лучше не отключать целиком: журнал фиксирует, кто и когда работал с данными, включая персональные данные сотрудников и клиентов, а учёт такого доступа требует 152-ФЗ. Разумнее сократить период хранения до нужного минимума, чем убирать журнал совсем и терять историю действий.

Где лучше хранить журнал регистрации, чтобы он не мешал базе?

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

Поможет ли перенос базы на другой сервер решить проблему с журналом?

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