1С и SQL: как перенаправить путь к хранению лога

Под «логом» в связке 1С и SQL обычно понимают два разных объекта: технологический журнал сервера 1С:Предприятия (каталог с дампами и файлами событий) и журнал транзакций базы данных SQL Server (файл с расширением .ldf). Оба со временем разрастаются и нередко заполняют системный диск, поэтому задача перенаправить путь их хранения — одна из самых частых у администраторов.

Перенос выполняется штатными средствами: для технологического журнала — через конфигурационный файл logcfg.xml, для журнала транзакций — через перемещение файлов базы средствами SQL Server. Ниже разобраны оба сценария с пошаговыми действиями, проверкой результата и разбором типичных ошибок.

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

Определяем, какой именно лог нужно перенаправить

Первый шаг — понять, какой журнал создаёт проблему. Технологический журнал 1С по умолчанию пишется в каталог вида C:\Program Files\1cv8\srvinfo\reg_1541 (папка с дампами и логами кластера) и включается только при наличии файла logcfg.xml. Журнал транзакций SQL Server — это файл .ldf, лежащий рядом с файлом данных .mdf, чаще всего в каталоге C:\Program Files\Microsoft SQL Server\...\DATA.

Признак проблемы с технологическим журналом — быстро растущая папка внутри каталога srvinfo с множеством файлов .log, .txt и дампов. Признак проблемы с журналом транзакций — файл .ldf, который занимает десятки гигабайт и продолжает расти, особенно если база работает в полной модели восстановления (FULL) без регулярного резервного копирования журнала.

Важно различать задачи «перенаправить путь» и «уменьшить размер». Если .ldf уже разросся, одного переноса мало — сначала нужно урезать журнал (перевести базу в SIMPLE и выполнить shrink либо настроить регулярный бэкап журнала при FULL), и только потом переносить файл на новый диск.

Перенаправляем технологический журнал 1С через logcfg.xml

Технологический журнал управляется файлом logcfg.xml, который размещается в каталоге conf сервера 1С (обычно C:\Program Files\1cv8\<версия>\bin\conf) либо в каталоге кластера. Если файла нет — журнал по умолчанию не ведётся или ведётся с минимальными настройками, и его можно создать с нуля сразу с нужным путём.

За каталог хранения отвечает атрибут location элемента log. Укажите путь на диске с достаточным свободным местом, например на отдельном томе D: или E:. Каталог должен существовать, и у учётной записи службы агента сервера 1С (по умолчанию USR1CV8) должны быть права на запись в него.

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c_logs\techlog" history="24">
    <event>
      <eq property="name" value=""/>
    </event>
    <property name="all"/>
  </log>
  <dump create="false"/>
</config>

Параметр history задаёт глубину хранения в часах — в примере журнал старше 24 часов удаляется автоматически. Это ключевая защита от переполнения диска: без ограничения глубины технологический журнал при полной записи событий способен заполнить любой том за считаные дни.

После сохранения logcfg.xml перезапустите службу «Агент сервера 1С:Предприятия» — настройки журнала подхватываются при старте. Проверьте, что в новом каталоге появились подкаталоги с именами процессов (rphost, rmngr, ragent) и внутри них начали создаваться файлы логов.

Переносим журнал транзакций SQL Server на другой диск

Перенос .ldf-файла выполняется средствами SQL Server. Самый безопасный способ для рабочей базы — перевести её в OFFLINE, переместить файл и указать новый путь. Сначала узнайте логические имена файлов базы запросом к sys.master_files или через свойства базы в SQL Server Management Studio на вкладке «Файлы».

Далее выполните последовательность: переведите базу в режим OFFLINE командой ALTER DATABASE [ИмяБазы] SET OFFLINE, физически скопируйте (лучше именно скопируйте, а не переместите) .ldf-файл в новый каталог, затем укажите SQL Server новый путь командой ALTER DATABASE [ИмяБазы] MODIFY FILE (NAME = логическое_имя_лога, FILENAME = 'E:\SQLData\ИмяБазы_log.ldf') и верните базу в работу: ALTER DATABASE [ИмяБазы] SET ONLINE.

1. 1
   Сделайте полную резервную копию базы данных
2. 2
   Узнайте логическое имя файла журнала через sys.master_files
3. 3
   Переведите базу в OFFLINE
4. 4
   Скопируйте .ldf-файл в новый каталог на целевом диске
5. 5
   Выполните ALTER DATABASE ... MODIFY FILE с новым путём
6. 6
   Верните базу в ONLINE и проверьте доступность из 1С
7. 7
   Убедившись в работоспособности, удалите старую копию файла

Учётная запись службы SQL Server должна иметь полные права на новый каталог — это обязательное условие, иначе база не вернётся в ONLINE с ошибкой доступа к файлу. Права проще всего выдать через свойства папки, указав виртуальную учётную запись вида NT SERVICE\MSSQLSERVER (или с именем экземпляра).

Альтернативный вариант — отсоединение базы (Detach) с последующим присоединением (Attach) через CREATE DATABASE ... FOR ATTACH с указанием новых путей ко всем файлам. Этот способ рабочий, но при OFFLINE-подходе меньше шагов и ниже риск потерять настройки базы.

Уменьшаем журнал транзакций перед переносом

Если .ldf разросся до десятков гигабайт, переносить его в таком виде бессмысленно — сначала журнал нужно сократить. При модели восстановления SIMPLE журнал урезается командой DBCC SHRINKFILE с указанием логического имени файла журнала. При модели FULL сначала выполните резервное копирование журнала транзакций, и только после этого shrink даст эффект.

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

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

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

После переноса .ldf выполните запрос к sys.master_files по базе и проверьте, что столбец physical_name для журнала указывает на новый путь. Затем запустите 1С, выполните несколько типовых операций (проведение документа, запись справочника) и убедитесь в отсутствии ошибок.

Типичные ошибки при переносе путей логов

Самая частая ошибка с технологическим журналом — забытый перезапуск службы агента сервера: logcfg.xml лежит правильно, но журнал продолжает писаться по старым правилам. Вторая типичная ситуация — отсутствие прав у учётной записи USR1CV8 на новый каталог, из-за чего журнал молча не пишется вовсе.

При переносе .ldf главные ошибки — перемещение файла без команды MODIFY FILE (SQL Server ищет файл по старому пути и не может поднять базу) и недостаточные права на новый каталог. Обе проблемы диагностируются по сообщениям об ошибках при попытке перевести базу в ONLINE.

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