Перенос информационной базы «1С:Предприятие 8.3» на новый сервер — стандартная задача для системного администратора или программиста. Однако часто после успешного запуска пользователи и руководство сталкиваются с неприятным сюрпризом: журнал регистрации оказывается абсолютно пустым, а новые события в нем не фиксируются. При этом сама база данных SQL работает без видимых сбоев и ошибок.
В этой статье мы подробно разберем, почему возникает эта проблема в клиент-серверном варианте работы 1С под управлением операционной системы Windows, проанализируем внутреннее устройство журнала регистрации и изучим пошаговые инструкции по восстановлению его работоспособности.
Для начала проясним важный архитектурный нюанс, который часто вводит в заблуждение начинающих специалистов. Несмотря на то, что сама база данных хранится на сервере СУБД (например, MS SQL Server или PostgreSQL), журнал регистрации физически не хранится внутри таблиц SQL. Платформа «1С:Предприятие 8.3» записывает журнал в файлы на сервере приложений 1С. Следовательно, обычного резервного копирования и восстановления базы средствами СУБД (через файлы .bak) недостаточно для переноса истории действий пользователей.
---
При переносе базы данных на новый сервер администрирования кластера 1С практически всегда создается новая информационная база в консоли кластера. В этот момент платформа автоматически генерирует для нее новый уникальный идентификатор — GUID (глобальный уникальный идентификатор).
Физически файлы журнала регистрации хранятся на сервере приложений 1С в каталоге:
C:\Program Files\1cv8\srvinfo\reg_1541\<GUID_базы>\1Cv8Log
Разберем по шагам, что происходит во время миграции:
GUID, например: a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d.srvinfo новую пустую папку с этим именем и вложенную папку 1Cv8Log с пустым файлом журнала.GUID.Решение проблемы:
Чтобы восстановить историю, нам необходимо сопоставить старые файлы журнала с новым идентификатором базы. Выполним следующие действия:
GUID нашей новой информационной базы (его можно посмотреть в свойствах базы).services.msc). Это необходимо, чтобы освободить занятые процессами файлы.C:\Program Files\1cv8\srvinfo\reg_1541\.GUID новой базы и откроем в ней каталог 1Cv8Log.1Cv8.lgd для нового формата SQLite или файлы .lgf и файлы папок дней для старого формата) и вставим их в эту папку с заменой существующих пустых файлов.---
Если старый журнал был перенесен корректно, но новые события все равно не регистрируются и журнал остается пустым с момента переноса, проблема кроется в правах доступа операционной системы Windows.
Запись в журнал регистрации осуществляет не клиентский компьютер и не СУБД, а рабочий процесс сервера приложений 1С — rphost. Этот процесс запускается от имени системного пользователя, назначенного службе «Агент сервера 1С:Предприятия». По умолчанию в ОС Windows это локальный пользователь USR1CV8 (или локальная система SYSTEM).
Выясним причину сбоя: при разворачивании системы на новом сервере Windows 10/11 или Windows Server учетной записи USR1CV8 часто забывают выдать полные права на чтение и запись в каталог хранения данных кластера (srvinfo).
Решение проблемы:
C:\Program Files\1cv8\.srvinfo (или непосредственно на вложенную папку 1Cv8Log нужной базы) и выберем пункт «Свойства».USR1CV8 (или той учетной записи, под которой запускается служба сервера 1С) в списке пользователей.1Cv8.lgd).---
Иногда журнал регистрации пустует из-за того, что в конфигурации или настройках режима Предприятия установлен уровень ведения журнала «Не регистрировать». Разработчики или администраторы могли намеренно или случайно отключить логирование.
Уровень ведения журнала регистрации может управляться программно с использованием встроенного языка 1С. Проанализируем ситуацию, при которой при старте системы отрабатывает следующий код:
УстановитьРежимЗаписиЖурналаРегистрации(РежимЗаписиЖурналаРегистрации.НеРегистрировать);
Если такое условие срабатывает, например, при проверке имени нового сервера или привязке к новой сетевой инфраструктуре, платформа перестает записывать любые события.
Также уровень логирования может быть изменен интерактивно. Посмотрим, как проверить и вернуть настройки через Конфигуратор и режим Предприятия:
Способ 1. Через Конфигуратор:
Способ 2. Через режим Предприятия (для версий платформы 8.3.17 и выше):
В современных версиях платформы управлять логированием можно непосредственно в режиме «1С:Предприятие» без монопольного доступа к базе. Для этого используется стандартная обработка управления настройками системы или программный интерфейс.
Рассмотрим пример кода, который возвращает стандартный режим записи всех событий:
ТекущийРежим = ПолучитьРежимЗаписиЖурналаРегистрации();
Если ТекущийРежим = РежимЗаписиЖурналаРегистрации.НеРегистрировать Тогда
УстановитьРежимЗаписиЖурналаРегистрации(РежимЗаписиЖурналаРегистрации.ВсеСобытия);
КонецЕсли;
---
Начиная с версии платформы 8.3.5, стандартным форматом для журнала регистрации стал формат базы данных SQLite (один файл с расширением .lgd). Это производительное решение, однако оно чувствительно к некорректному завершению работы сервера приложений, сбоям электропитания или ошибкам файловой системы.
Если во время переноса базы данных файлы журнала копировались «на горячую» (при работающей службе 1С) или произошел сбой сети, структура SQLite могла повредиться (в логах это отражается как внутренняя ошибка базы данных database disk image is malformed).
При повреждении файла 1Cv8.lgd платформа 1С теряет возможность производить новые записи. Журнал регистрации в режиме Предприятия при этом открывается абсолютно пустым.
Решение проблемы:
Проанализируем шаги по восстановлению поврежденного файла SQLite:
1Cv8.lgd из каталога журнала в надежное место.sqlite3.exe (ее можно скачать с официального сайта SQLite).
sqlite3 1Cv8.lgd ".clone 1Cv8_recovered.lgd"
Если клонирование прошло успешно, переименуем восстановленный файл 1Cv8_recovered.lgd обратно в 1Cv8.lgd, вернем его в исходный каталог, настроим права доступа и запустим службу 1С.
Если восстановить файл не удается, временно перенесем старый поврежденный файл из каталога. При запуске служба сервера 1С автоматически создаст новый чистый файл 1Cv8.lgd, и запись событий начнется с нуля.
---
По умолчанию каталог srvinfo располагается на системном диске C:\ сервера приложений 1С. При переносе информационной базы на новый сервер (особенно если это персональный компьютер под управлением Windows 10, используемый в качестве временного сервера) дисковое пространство может быстро закончиться.
База данных SQLite при нехватке свободного места блокирует транзакции на запись, чтобы не допустить окончательного разрушения структуры файла. В итоге старые записи доступны для чтения, но новые события не добавляются, из-за чего создается видимость "застывшего" или пустого журнала за последние дни.
Решение проблемы:
C:\ сервера приложений.srvinfo на другой логический диск с большим объемом памяти (это делается путем изменения параметров запуска службы в реестре Windows или через настройки утилиты запуска сервера 1С).---
В процессе обсуждения часто возникает вопрос: а не стер ли кто-то файлы журнала регистрации вручную перед или во время переноса? Выясним это с помощью анализа файловой системы и логов операционной системы.
1Cv8Log на новом сервере. Посмотрим на дату создания и изменения файла 1Cv8.lgd. Если дата создания совпадает со временем переноса базы на новый сервер, а размер файла составляет всего несколько десятков килобайт, это указывает на то, что старый журнал не переносился вовсе или был удален перед запуском службы, а система создала новый пустой файл.eventvwr.msc), перейдем в раздел «Логи Windows» — «Безопасность». Нам необходимо отфильтровать события по ID 4660 (объект был удален) и ID 4663 (попытка доступа к объекту). В деталях события будет указано имя пользователя ОС, совершившего операцию с файлом журнала регистрации.Таким образом, мы детально рассмотрели все возможные причины пустеющего журнала регистрации после миграции базы данных. Своевременный контроль соответствия GUID баз, настройка прав доступа пользователя USR1CV8 и периодическая проверка дискового пространства позволят вам гарантировать сохранность истории действий пользователей в вашей системе.