К статье
Практический материал

Администрирование · 10 мин

Журнал транзакций в 1С: назначение, хранение и практическая работа

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

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

Термин «журнал транзакций» в контексте 1С используется в двух смыслах, и их важно различать. В файловом варианте работы (особенно в версиях платформы 7.7) это файл 1Cv7.LOG в каталоге базы. В клиент-серверном варианте на MS SQL Server или PostgreSQL журнал транзакций ведёт сама СУБД (в MS SQL это файл с расширением .ldf). В обоих случаях логика одна: сначала изменение фиксируется в журнале, потом применяется к данным.

Администратору и бухгалтеру полезно понимать, как устроен этот механизм: от него зависят скорость работы базы, размер файлов на диске, возможность «откатить» случайное удаление документов и корректность резервного копирования. Ниже разобраны назначение журнала, места его хранения, способы просмотра, урезания и типичные ошибки, которые приводят к потере данных.

Для чего нужен журнал транзакций

Основная функция журнала — гарантия атомарности и целостности. Когда пользователь проводит документ, платформа не переписывает сразу все таблицы. Сначала в журнал записывается намерение изменить данные и само содержимое изменения. Только после успешной записи в журнал изменение применяется к основным таблицам базы.

Если в этот момент пропало питание или сервер перезагрузился, при следующем запуске система читает журнал и «доигрывает» незавершённые транзакции либо откатывает неподтверждённые. Благодаря этому база не остаётся в половинчатом состоянии, когда документ проведён, а движения по регистрам записаны частично.

Вторая функция — восстановление на момент времени. В клиент-серверном варианте при полной модели восстановления SQL Server журнал транзакций позволяет вернуть базу не только к последней резервной копии, но и к любой секунде до нештатного события, например к состоянию прямо перед случайным удалением документов.

Где хранится журнал в разных вариантах работы 1С

В файловой базе 1С:Предприятие 7.7 журнал транзакций — это файл 1Cv7.LOG, лежащий в каталоге информационной базы рядом с файлами данных. Рядом могут находиться служебные файлы-описатели. Размер файла растёт по мере работы пользователей и не уменьшается сам по себе.

В файловом варианте 1С 8.x отдельного классического журнала транзакций нет — механизм целостности встроен в сам файл 1Cv8.1CD. Однако понятие журнала сохраняется на уровне СУБД, если база работает в клиент-серверном режиме.

В клиент-серверном варианте на MS SQL Server журнал транзакций — это файл с расширением .ldf, создаваемый вместе с базой данных. Его расположение задаётся при создании базы, посмотреть путь можно в свойствах базы в SQL Server Management Studio на вкладке «Files». В PostgreSQL аналогичную роль играет WAL (журнал предзаписи), хранящийся в каталоге pg_wal внутри каталога данных сервера.

Чем журнал транзакций отличается от журнала регистрации

Путаница между этими двумя механизмами — частая причина неверных действий. Журнал регистрации отвечает на вопрос «кто и что делал в системе»: кто вошёл, какой документ изменил, какие ошибки возникли. Он хранится в читаемом виде и доступен через конфигуратор или типовые обработки.

Журнал транзакций отвечает на вопрос «как не потерять данные при сбое». Это двоичный файл, который читается только платформой или СУБД. Открыть его блокнотом и посмотреть, кто удалил документ, не получится — для аудита действий пользователей служит именно журнал регистрации.

КритерийЖурнал транзакцийЖурнал регистрации
НазначениеЦелостность и восстановление данныхАудит действий и диагностика ошибок
Кто читаетПлатформа и СУБД автоматическиАдминистратор, пользователь с правами
ФорматДвоичный, служебныйТабличный, просматривается в конфигураторе
Где смотретьФайловая система, средства СУБДКонфигуратор → Администрирование → Журнал регистрации

Как журнал транзакций помогает восстановить данные

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

В клиент-серверном варианте на MS SQL при полной модели восстановления (Full recovery model) журнал позволяет выполнить восстановление на момент времени. Порядок такой: восстанавливается последняя полная копия, затем последовательно накатываются копии журнала транзакций до нужной секунды. Это стандартный приём при случайном массовом удалении данных.

Восстановление базы на момент времени (MS SQL)
  1. 1
    Переведите базу в однопользовательский режим и запретите работу пользователей 1С
  2. 2
    Сделайте резервную копию хвоста журнала транзакций (tail-log backup)
  3. 3
    Восстановите последнюю полную копию базы с параметром NORECOVERY
  4. 4
    Последовательно примените резервные копии журнала транзакций с NORECOVERY
  5. 5
    Укажите целевой момент времени через STOPAT и завершите восстановление с RECOVERY
  6. 6
    Проверьте наличие нужных документов и только потом откройте доступ пользователям

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

Почему журнал разрастается и как его урезать

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

Есть два безопасных пути. Если восстановление на момент времени не требуется, переключите базу в простую модель восстановления — журнал начнёт усекаться автоматически, а затем выполните сжатие файла (shrink) один раз, чтобы вернуть место на диске. Если восстановление на момент времени нужно, настройте регулярное резервное копирование журнала транзакций, например каждые 15–60 минут: после каждой копии занятое место внутри файла освобождается.

В файловой базе 7.7 урезание журнала выполняется через режим конфигуратора: «Администрирование → Урезать журнал транзакций». Операция удаляет записи о завершённых транзакциях и требует монопольного доступа к базе.

Типичные ошибки
01
Удаление 1Cv7.LOG или .ldf ради освобождения места — база перестаёт открываться, данные с момента последней копии теряются
02
Полная модель восстановления без копий журнала — файл .ldf растёт до переполнения диска и остановки работы пользователей
03
Регулярное сжатие (shrink) файла журнала по расписанию — приводит к фрагментации и падению производительности; сжатие допустимо как разовая мера
04
Отсутствие проверки, что резервные копии журнала реально создаются и читаются — в момент сбоя выясняется, что восстановить нечего

Как проверить состояние журнала и настроить контроль

Минимальный регулярный контроль включает три вещи: размер файла журнала на диске, модель восстановления базы и факт успешного создания резервных копий. В MS SQL размер и заполненность журнала видны в отчётах Management Studio или запросом к sys.dm_db_log_space_usage. Модель восстановления проверяется в свойствах базы на вкладке «Options».

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

Контрольные точки

Как проверить результат

Размер файла журнала
Норма

Размер стабилен и соответствует объёму ежедневных изменений

Тревожный признак

Файл непрерывно растёт неделями и занимает значительную часть диска

Модель восстановления базы
Норма

Simple — если не нужен откат на момент времени; Full — с регулярными копиями журнала

Тревожный признак

Full без расписания резервного копирования журнала

Резервные копии
Норма

Копии создаются по расписанию, тестовое восстановление проходит успешно

Тревожный признак

Копии формально настроены, но никогда не проверялись восстановлением

Частые вопросы о журнале транзакций 1С

Можно ли посмотреть в журнале транзакций, кто удалил документ?

Нет. Журнал транзакций — двоичный служебный файл, он не предназначен для чтения человеком и не привязан к пользователям. Для поиска автора действий используйте журнал регистрации: в конфигураторе откройте «Администрирование → Журнал регистрации» и отфильтруйте события по типу «Данные. Удаление».

Что будет, если удалить файл 1Cv7.LOG в базе 7.7?

Платформа при запуске создаст новый пустой журнал, но все незавершённые на момент удаления транзакции будут потеряны, а при повреждённом журнале база может вообще не открыться. Удаление допустимо только как крайняя мера после полной архивной копии и при заведомо «здоровой» базе, когда другие способы запуска исчерпаны.

Нужен ли журнал транзакций в файловой базе 1С 8?

Отдельного файла журнала в формате 1С 8 для файловой базы нет — механизм обеспечения целостности встроен в файл 1Cv8.1CD. Вопросы управления журналом возникают только при переходе на клиент-серверный вариант с MS SQL, PostgreSQL или Oracle.

Какую модель восстановления выбрать для базы 1С на SQL Server?

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

Почему после сжатия журнал снова быстро вырос?

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

Можно ли перенести файл журнала на другой диск?

Да, и это разумная практика: размещение журнала на отдельном физическом диске ускоряет запись транзакций. В MS SQL перенос выполняется через отсоединение базы, перемещение .ldf-файла и повторное присоединение с указанием нового пути, либо через ALTER DATABASE ... MODIFY FILE. Операцию выполняйте при остановленной работе пользователей и с актуальной резервной копией.

Итог

Что важно запомнить

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