Журнал регистрации 1С повреждён или пуст: как вернуть события и починить файлы

Журнал регистрации 1С восстанавливают на уровне файлов, а не через Конфигуратор: это папка 1Cv8Log рядом с файловой базой или в каталоге кластера на сервере. Повреждённый файл журнала откладывают в сторону, платформа создаёт новый, а старые события достают из резервной копии этой папки или чинят SQLite-файл 1Cv8.lgd утилитой sqlite3. Выгрузка .dt и бэкап SQL журнал не содержат, поэтому вернуть из них историю событий нельзя.

Способ зависит от цели. Нужно, чтобы база снова писала журнал и не падала с ошибкой, — хватит «чистого старта». Нужно вернуть историю для расследования (кто удалил документ, кто менял права) — придётся проверять целостность, чинить файл или поднимать копию каталога.

Всё ниже относится к платформе 8.3 и не зависит от конфигурации: журнал одинаково устроен в Бухгалтерии, ЗУП, УТ и любой другой базе.

Где хранится журнал регистрации и почему он ломается

Журнал — это не таблица в базе данных, а отдельные файлы. Отсюда все особенности восстановления.

Расположение файлов

Каталог srvinfo по умолчанию находится в папке установки платформы или в профиле пользователя, от имени которого работает служба сервера. Точный путь видно в параметрах запуска службы агента сервера (ключ -d).

GUID базы удобно узнать в консоли администрирования кластера: в свойствах информационной базы. Другой способ — открыть каталог reg_1541: там лежит по папке на каждую базу кластера, и нужная обычно самая «тяжёлая» по журналу.

Два формата журнала

• 📄 Старый, последовательный. Файл-словарь 1Cv8.lgf (пользователи, компьютеры, объекты метаданных) и файлы событий *.lgp, по одному на период. Имя .lgp содержит дату начала периода, например 20260901000000.lgp.
• 🗄 SQLite. Один файл 1Cv8.lgd — обычная база SQLite со всеми событиями внутри. Формат появился в платформе 8.3.5.

Какой формат у вашей базы, видно по содержимому 1Cv8Log. Есть 1Cv8.lgd — SQLite. Есть 1Cv8.lgf и пачка .lgp — старый формат.

Что обычно портит журнал

• 💥 Аварийное выключение сервера или компьютера с файловой базой во время записи.
• 💾 Закончилось место на диске: файл журнала дописан наполовину.
• 🛡 Антивирус проверяет или блокирует файлы журнала во время записи.
• 📈 Журнал разросся до десятков гигабайт: открытие идёт часами, отбор зависает.
• 📂 Файловая база лежит на сетевой папке с нестабильным соединением.
• 🧹 Кто-то вручную удалил или скопировал часть файлов при работающей базе.

Диагностика: что именно случилось с журналом

Сначала поймите, с чем имеете дело. От этого зависит, какой из способов ниже нужен.

Уровень регистрации проверяют в Конфигураторе: Администрирование → Настройка журнала регистрации. Если там стоит «Не регистрировать», журнал пуст не из-за сбоя: события просто не пишутся.

Размер журнала смотрите в проводнике по папке 1Cv8Log. Файл 1Cv8.lgd на 20–50 ГБ — это уже не поломка, а запущенное обслуживание.

Проверка целостности журнала и базы: что за что отвечает

Частая ошибка — запускать на повреждённый журнал инструменты, которые его не касаются.

Если вместе с журналом пострадала и сама база (например, после того же аварийного отключения), тестирование нужно, но это отдельная задача. Оно требует монопольного доступа, поэтому запускайте его, когда все пользователи вышли.

Проверка файла SQLite

Работайте только с копией файла. Скопируйте 1Cv8.lgd в отдельную папку, например D:\lgcheck\, и скачайте консольную утилиту sqlite3 с официального сайта SQLite.

cd /d D:\lgcheck
sqlite3.exe 1Cv8.lgd "PRAGMA integrity_check;"

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

Способ 1. Чистый старт: сбросить повреждённый журнал

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

Файловая база

1. Попросите всех выйти из базы и убедитесь, что процессов 1cv8.exe и 1cv8c.exe с этой базой не осталось.
2. Переименуйте папку 1Cv8Log, например в 1Cv8Log_broken_0910.
3. Запустите базу. Платформа создаст новую пустую папку 1Cv8Log и начнёт писать события заново.
4. Проверьте, что журнал открывается и в нём появились события вашего входа.

Клиент-серверная база

1. Найдите папку базы по GUID в каталоге reg_1541.
2. Остановите службу агента сервера 1С в оснастке «Службы» Windows или командой systemctl на Linux.
3. Переименуйте 1Cv8Log в этой папке.
4. Запустите службу и войдите в базу.

Если вы хотите сменить формат с SQLite на старый (а это частый совет при постоянных сбоях больших .lgd), после переименования создайте новую папку 1Cv8Log и положите в неё пустой файл 1Cv8.lgf. Платформа увидит файл старого формата и продолжит писать в нём.

Способ 2. Ремонт файла 1Cv8.lgd через SQLite

Нужен, когда историю обязательно вернуть, а свежей копии нет. Работайте с копией, оригинал не трогайте до конца.

Пересборка через .recover

Команда .recover есть в sqlite3 начиная с версии 3.29. Она вытаскивает всё, что можно прочитать, в том числе из повреждённых страниц.

cd /d D:\lgcheck
sqlite3.exe 1Cv8.lgd ".recover" > dump.sql
sqlite3.exe 1Cv8_new.lgd < dump.sql
sqlite3.exe 1Cv8_new.lgd "PRAGMA integrity_check;"

Если последняя команда ответила ok, у вас целый файл. Записи с разрушенных страниц будут потеряны, остальное сохранится.

Пересборка через .dump

На старых версиях sqlite3 или если .recover падает, попробуйте классический дамп:

sqlite3.exe 1Cv8.lgd ".dump" > dump.sql
sqlite3.exe 1Cv8_new.lgd < dump.sql

.dump останавливается на первой нечитаемой странице, поэтому восстановленных событий обычно меньше.

Как подложить исправленный файл

1. Остановите базу (файловая) или службу сервера (клиент-сервер) — с тем же предупреждением о сеансах.
2. Перенесите текущий 1Cv8.lgd в сторону.
3. Переименуйте 1Cv8_new.lgd в 1Cv8.lgd и положите в папку 1Cv8Log.
4. Запустите базу и откройте журнал с отбором за нужный период.

Не правьте таблицы .lgd SQL-запросами вручную: удаление «лишних» строк легко ломает ссылки на словари пользователей и метаданных. Чистить старые события надо штатным сокращением журнала (о нём ниже).

Способ 3. Старый формат: заменить повреждённые .lgp и словарь .lgf

В последовательном формате повреждение почти всегда локальное. Ломается один .lgp за период, когда случился сбой, а остальные целые.

1. Скопируйте всю папку 1Cv8Log в отдельное место.
2. Отсортируйте .lgp по имени: имя — дата начала периода. Найдите файл, на котором открытие журнала падает. Подсказка — ошибка при отборе за конкретные даты.
3. Откройте подозрительный файл в текстовом редакторе, который справляется с большими файлами. Обрыв посреди записи или мусор в конце — признак повреждения.
4. Перенесите этот файл из папки 1Cv8Log в сторону. Журнал откроется, события за остальные периоды будут на месте.
5. Если повреждённый файл всё-таки нужен, сделайте его копию и удалите в ней хвост после последней целой записи. Это ручная работа, и результат проверяйте в пустой файловой базе, а не в рабочей.

Со словарём 1Cv8.lgf так не получится. В нём коды пользователей, компьютеров и объектов, на которые ссылаются все .lgp. Если словарь заменить чужим или более старым, события откроются, но с неверными именами. Поэтому 1Cv8.lgf берите только из той же копии, что и .lgp.

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

Это единственный надёжный способ вернуть историю целиком. Но сначала главное ограничение.

Что из этого следует на практике:

• 🔹 После Загрузить информационную базу из .dt журнал целевой базы остаётся своим. Старых событий исходной базы в нём не будет.
• 🔹 Восстановили SQL-бэкап в новую базу кластера — у неё новый GUID и новый пустой журнал.
• 🔹 История есть только там, где лежит папка 1Cv8Log: в исходной папке базы, в копии диска, в архиве каталога srvinfo.

Порядок восстановления из файловой копии

1. Найдите в резервной копии папку 1Cv8Log нужной базы. Для сервера — по GUID в reg_1541.
2. Решите, куда восстанавливать. В рабочую базу — только если текущие события после копии не нужны. Иначе — в отдельную пустую файловую базу , только для просмотра.
3. Для рабочей базы: остановите базу или службу сервера, переименуйте текущую 1Cv8Log, скопируйте папку из копии, запустите.
4. Для просмотра: создайте пустую файловую базу, замените её 1Cv8Log папкой из копии и откройте Администрирование → Журнал регистрации в Конфигураторе или режиме Предприятия.

Если базу перенесли на другой сервер

При переносе клиент-серверной базы через .dt историю тоже можно сохранить. Скопируйте папку 1Cv8Log со старого сервера в папку новой базы на новом сервере (по её GUID), пока служба остановлена. Формат файлов от сервера не зависит.

Профилактика: чтобы журнал регистрации больше не пришлось восстанавливать

Большинство повреждений случается с журналом, за которым никто не следит. Набор мер короткий.

Сокращение и разделение журнала

Оба действия делаются в Конфигураторе: Администрирование → Настройка журнала регистрации.

• ✂️ Сокращение. Кнопка удаляет события до выбранной даты. Поставьте флажок сохранения удаляемых событий в файл: тогда старая история уйдёт в архив, а не в никуда. Операция на большом журнале идёт долго, запускайте её вечером.
• 📅 Разделение по периодам. Новые события пишутся в отдельные файлы по дням, неделям или месяцам. Сбой портит один период, а не весь журнал. Старые периоды проще архивировать и удалять.

Какой уровень регистрации выбрать

Для бухгалтерских баз обычно нужен уровень «Информация»: без него в журнале не видно, кто удалил или перепровёл документ. Тогда обязательно разделяйте журнал по периодам — он растёт быстро.

Резервная копия папки журнала

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

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