Как почистить логи базы 1С без потери данных

Журналы и лог-файлы 1С со временем разрастаются до десятков гигабайт и начинают мешать работе: база медленнее открывается, диск переполняется, резервные копии становятся тяжёлыми. Чаще всего проблему создают два источника — журнал регистрации самой платформы 1С и журналы транзакций СУБД, если база работает в клиент-серверном варианте.

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

Ниже разобраны оба сценария: как сократить журнал регистрации в файловой и клиент-серверной базе, как безопасно усекать transaction log в MS SQL и PostgreSQL, как настроить хранение, чтобы логи не разрастались снова, и каких ошибок при очистке стоит избегать.

Определяем, какие логи заняли место

Прежде чем что-то удалять, выясните, что именно съело дисковое пространство. В файловой базе проверьте размер файлов в каталоге базы: 1Cv8.1CD (сама база) и подкаталог 1Cv8Log с файлом 1Cv8.lgd (журнал регистрации). Если журнал занимает гигабайты — он и есть виновник.

В клиент-серверном варианте смотрите на файлы базы данных на стороне СУБД. В MS SQL Server большой размер файла .ldf говорит о разросшемся журнале транзакций, а большой .mdf — о данных, которые чистятся иначе. Также журнал регистрации в клиент-серверной базе хранится отдельно — в каталоге srvinfo кластера 1С, в папке вида reg_1541\<GUID базы>\1Cv8Log.

Сокращаем журнал регистрации через конфигуратор

Штатный способ очистки журнала регистрации — сокращение через конфигуратор. Откройте базу в конфигураторе, перейдите в меню «Администрирование → Настройка журнала регистрации» и нажмите кнопку «Сократить». В появившемся окне выберите дату, до которой удалять события, и укажите файл, куда выгрузить удаляемую часть, если история может понадобиться.

На время сокращения пользователям лучше завершить работу: операция требует монопольного доступа к журналу и на больших файлах может занять значительное время. В клиент-серверном варианте сокращение выполняется на стороне сервера 1С, но общая рекомендация о минимальной нагрузке сохраняется.

После сокращения старый файл журнала заменяется новым, а выгруженная часть сохраняется в указанный каталог в формате журнала — её можно открыть позже через конфигуратор («Файл → Открыть») и просмотреть события как обычный журнал регистрации.

1. 1
   Сделайте резервную копию базы или каталога с журналом
2. 2
   Попросите пользователей выйти из базы
3. 3
   Откройте конфигуратор: Администрирование → Настройка журнала регистрации
4. 4
   Нажмите «Сократить», укажите дату и файл для выгрузки удаляемых событий
5. 5
   Дождитесь завершения и проверьте, что журнал открывается и новые события пишутся

Настраиваем хранение, чтобы журнал не разрастался

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

Дополнительно в свойствах базы (в консоли кластера 1С для клиент-серверного варианта) доступен параметр периодичности разделения журнала регистрации: по дням, неделям, месяцам или годам. Разделение по периодам упрощает архивацию и удаление старых фрагментов — старый период можно просто перенести в архив, не запуская сокращение.

Чистим логи СУБД в клиент-серверной базе

Если место съедает журнал транзакций MS SQL Server, действия выполняются средствами СУБД. Классическая причина разрастания .ldf-файла — база работает в полной модели восстановления (Full), но резервные копии журнала транзакций не делаются. В этом режиме лог растёт бесконечно, пока его не усечь.

Есть два рабочих подхода. Первый: если восстановление на произвольный момент времени не требуется, переведите базу в простую модель восстановления (Simple) — тогда журнал усекается автоматически после checkpoint, а разросшийся файл сжимается командой shrink. Второй: оставить модель Full, но настроить регулярные бэкапы журнала транзакций — каждый такой бэкап освобождает место внутри .ldf, после чего файл можно сжать до разумного размера.

-- Пример для простой модели восстановления
ALTER DATABASE [MyBase] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase_log', 1024); -- сжать лог до ~1 ГБ
GO

В PostgreSQL аналогичную роль играют WAL-файлы. Их накопление обычно связано с остановленной репликой, слотом репликации или слишком большим значением max_wal_size. Удалять WAL-файлы вручную из каталога pg_wal нельзя — это почти гарантированно повредит кластер. Вместо этого устраняют причину накопления и дают серверу удалить файлы автоматически.

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

Технически файл 1Cv8.lgd можно удалить при остановленной базе — платформа создаст новый пустой журнал при следующем запуске. Но это грубый метод: вся история событий теряется без возможности выгрузки, а при неаккуратных действиях (например, удалении файла при запущенном сервере 1С) возможны ошибки записи журнала.

Безопасный вариант ручной очистки: остановить работу с базой (для клиент-серверного варианта — остановить службу агента сервера 1С или хотя бы завершить сеансы), переименовать или переместить файл журнала в архивный каталог, затем запустить работу. Так старый журнал сохраняется и при необходимости открывается отдельно.

Проверяем результат и предотвращаем повторение

После очистки убедитесь, что база работает штатно: журнал регистрации открывается и в него пишутся новые события, пользователи входят без ошибок, а размер файлов на диске действительно уменьшился. Для СУБД дополнительно проверьте модель восстановления и расписание бэкапов.

Чтобы проблема не вернулась, встройте обслуживание логов в регламент: сокращение журнала регистрации — например, раз в квартал с выгрузкой в архив, бэкапы журнала транзакций — по расписанию, если используется модель Full. Контролируйте свободное место на дисках с базами — переполнение диска во время работы СУБД опаснее самих разросшихся логов.

Частые вопросы о чистке логов 1С