При миграции информационных баз 1С:Предприятие между серверами часто возникает потребность сохранить накопленную историю событий — журнал регистрации. Поскольку в современных версиях платформы 1С журнал переведен в формат .lgd (база данных SQLite), простое копирование файлов может привести к их повреждению. Давайте разберем, как выполнить эту задачу технически грамотно и избежать потери данных.
Сервер 1С:Предприятие работает с файлами журнала регистрации в монопольном режиме. Пока служба Агент сервера 1С:Предприятия запущена, она постоянно производит запись транзакций в файл .lgd. Если вы попытаетесь скопировать файл «на лету», вы рискуете получить неконсистентную копию, что приведет к ошибке формата базы данных при попытке прочитать журнал на новом сервере.
Это самый надежный метод, который гарантирует целостность данных. Выполним перенос пошагово:
services.msc) и остановите службу Агент сервера 1С:Предприятие. Это закроет все файловые дескрипторы и сбросит кэш транзакций на диск.srvinfo (обычно она находится по пути C:\Program Files\1cv8\srvinfo\). Внутри вы увидите подкаталоги с именами, соответствующими GUID баз данных.GUID соответствует вашей базе, посмотрите свойства базы в консоли администрирования серверов 1С (раздел «Свойства» базы данных).GUID на новый сервер в аналогичный каталог srvinfo. Рекомендуется копировать всю папку целиком, так как она содержит не только файл данных 1cv8.lgd, но и сопутствующие файлы индексов.Агент сервера 1С:Предприятие обратно.Если полная остановка службы сервера 1С недопустима (например, в кластере работают другие базы, которые нельзя отключать), можно воспользоваться технологией теневого копирования томов (VSS — Volume Shadow Copy Service). Этот метод позволяет сделать «снимок» диска в момент времени, когда данные зафиксированы в консистентном состоянии.
Разберем этапы работы с теневым копированием:
Важное замечание: Даже при использовании VSS, после переноса файла крайне желательно запустить «Конфигуратор» на новом сервере и при необходимости выполнить операцию сжатия или тестирования журнала регистрации, чтобы убедиться в отсутствии логических повреждений данных SQLite.
В процессе обсуждения мы выяснили, что при создании новой базы на новом сервере платформа присваивает ей новый уникальный GUID. Если вы создали базу заново (пустую), то в директории srvinfo появится новая папка с другим GUID. Чтобы «подключить» старый журнал к новой записи в кластере, сделайте следующее:
GUID вашей базы на новом сервере.GUID (привезенную с прошлого сервера) в GUID, который был присвоен базе на новом сервере.GUID, и уже после этого заменить папку в srvinfo, пока база еще не успела нагенерировать большое количество новых записей.Если в процессе переноса возникли ошибки, у вас всегда остается штатный инструмент для сохранения истории событий. В режиме Конфигуратор или через Администрирование вы можете выполнить выгрузку журнала в текстовый формат (.txt или .xml). Это позволит сохранить историю для аудита, даже если файл .lgd не удается подключить к серверу.
Помните, что регулярное обслуживание Журнала регистрации, включая его периодическое сжатие, является залогом стабильной работы сервера 1С. Не забывайте анализировать ситуацию перед выполнением действий с файловой системой и всегда имейте резервную копию каталога srvinfo!