Часто системные администраторы и специалисты по 1С сталкиваются с пугающей ситуацией: при создании полного бэкапа базы данных средствами SQL-сервера, журнал регистрации (ЖР) в эту резервную копию не попадает. Если база "падает" или нужно провести расследование действий пользователей за прошлый месяц на копии базы, выясняется, что логов нет. Давайте подробно разберем, почему так происходит, и рассмотрим эффективные методы создания резервных копий журнала регистрации, а также способы оптимизации его размера.
СУБД (например, MS SQL Server или PostgreSQL) отвечает только за хранение таблиц самой конфигурации и пользовательских данных. Журнал регистрации в архитектуре платформы 1С:Предприятие хранится отдельно и независимо на уровне файловой системы сервера приложений 1С. Поэтому стандартный бэкап средствами SQL его не захватывает. Нам необходимо использовать файловые инструменты резервного копирования для папки кластера сервера 1С.
Самый простой, но требующий технологического окна способ — это манипуляции с файлами при остановленной службе сервера 1С. Рассмотрим по шагам, как мы можем это сделать:
1Cv8.lgd).Этот способ надежен, но совершенно не подходит для баз, работающих в режиме 24/7, где остановка даже на пару минут критична для бизнеса.
Если мы не хотим или не можем останавливать сервер, одним из рабочих решений является использование старого формата журнала регистрации. В этом формате платформа разбивает логи на отдельные текстовые файлы по периодам (например, по дням).
Проанализируем преимущества такого подхода: мы включаем старый формат и сегментацию по дням. В таком случае файл за текущий день платформа держит открытым для записи, а вот файлики за предыдущие дни (с расширением .lgp) мы можем совершенно спокойно копировать, архивировать или удалять прямо во время работы базы, не блокируя работу пользователей.
Важное техническое замечание: Начиная с релиза 1С 8.3.12 платформа позволяет переключать формат журнала (со старого на новый и обратно) штатными средствами через конфигуратор или консоль администрирования. В более ранних релизах (например, 8.3.8) для перехода на старый формат приходилось прибегать к хитростям: останавливать сервер, удалять базу из кластера, подкладывать пустой файл с расширением старого формата и переподключать базу.
Новый формат журнала регистрации представляет собой полноценную базу данных SQLite (один большой файл 1Cv8.lgd). Копировать этот файл обычными средствами Windows во время работы пользователей категорически не рекомендуется. Из-за незавершенных транзакций записи высок риск получить битый архив, который потом невозможно будет прочитать.
Для создания бэкапа без остановки сервера 1С нам потребуется использовать механизмы теневого копирования тома. В ОС Windows это служба VSS (Volume Shadow Copy Service). Программы для резервного копирования, умеющие работать с VSS, создают мгновенный "слепок" файловой системы, гарантируя целостность базы SQLite даже при интенсивной записи.
Платформа 1С позволяет настроить автоматизированное обслуживание журнала через запуск Конфигуратора в пакетном режиме. Это отличный способ отрезать старые записи из рабочей базы и сохранить их в архив. Посмотрим на пример команды для командной строки:
"C:\Program Files\1cv8\8.3.xx.xxx\bin\1cv8.exe" DESIGNER /S"ServerName\BaseName" /N"Admin" /P"Password" /ReduceEventLogSize 2023-10-01 -saveAs "D:\Backups\EventLog_archive.elf"
Параметр /ReduceEventLogSize указывает границу даты, до которой нужно отрезать события, а ключ -saveAs задает путь к файлу архива. Этот процесс мы можем добавить в Планировщик задач Windows и запускать глубокой ночью.
Часто администраторы сталкиваются с аномальным разрастанием файла 1Cv8.lgd. В некоторых случаях его размер может составлять 150 Гб с приростом по 2-3 Гб ежедневно. Выясним причину: чаще всего такой объем создают не действия пользователей, а логи старта, хода выполнения и завершения фоновых и регламентных заданий.
Разберем важный нюанс: если мы очистим старые записи из журнала через конфигуратор, физический размер файла .lgd на диске не уменьшится! СУБД SQLite просто помечает страницы внутри файла как свободные для новых данных.
Чтобы физически сжать файл (вернуть место на диске), нам необходимо выполнить дефрагментацию базы данных SQLite. Для этого:
sqlite3.exe.VACUUM для нашего файла ЖР.Если в базе генерируется слишком много служебного мусора, мы можем очистить его точечно напрямую через SQL-запросы к файлу логов с помощью команды DELETE FROM EventLog WHERE..., удалив записи, генерируемые служебными фоновыми заданиями.
Если наша база высоконагруженная (сотни пользователей, интенсивная работа), хранение файла журнала регистрации размером более 10-20 Гб становится проблемой. Стандартный просмотр логов в 1С начинает безнадежно зависать. В таких случаях мы можем применить следующие практики:
1Cv8.lgd на отдельные быстрые NVMe/SSD диски. Это снизит нагрузку на дисковую подсистему основной СУБД.Применяя эти методы, мы сможем обеспечить надежное хранение истории действий пользователей, сохранить высокую производительность системы и всегда иметь под рукой актуальные бэкапы журнала регистрации.