← На главную

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

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

Выясняем причины сбоя работы Effector Saver

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

Для решения проблемы нам необходимо проработать три ключевых направления:

1. Восстановить работоспособность COM-объекта V83.ComConnector в операционной системе Windows Server.
2. Настроить параметры блокировки сеансов и задать верный код разрешения (параметр /UC) в консоли администрирования 1С и в самом Effector Saver.
3. Отрегулировать параметры завершения зависших и спящих сеансов на уровне конфигуратора 1С для предотвращения монопольных блокировок.
4. Понять разницу между логическим бэкапом (выгрузкой в формат .dt) и физическим бэкапом базы данных на уровне СУБД.

Шаг 1. Исправление проблемы с COM-объектом V83.ComConnector

Программа Effector Saver управляет сеансами на сервере (подключается к кластеру, блокирует новые соединения и программно завершает текущие) через COM-соединение. При установке новой версии платформы 1С регистрация старой библиотеки comcntr.dll в операционной системе Windows затирается, а новая библиотека часто не регистрируется автоматически из-за нехватки прав или особенностей установщика 1С. Для быстрой проверки регистрации библиотеки и выявления конфликтов платформ можно использовать обработку для диагностики COM-соединения.

Рассмотрим подробнее процесс ручной регистрации компоненты:

1. Сначала убедимся, что компонент для COM-соединения вообще установлен на сервере. Для этого перейдем в Панель управления -> Программы и компоненты, найдем в списке установленную платформу 1С:Предприятие, нажмем кнопку Изменить и в появившемся дереве компонентов проверим наличие флага напротив пункта COM-соединение. Если он отсутствует, установим его. Без этого компонента файл библиотеки просто отсутствует на диске.
2. Запустим командную строку cmd.exe строго от имени администратора. Это обязательное условие, иначе операционная система заблокирует изменения в реестре Windows.
3. Выполним команду разрегистрации старой библиотеки, чтобы очистить возможные некорректные и "битые" записи в реестре:

regsvr32 /u "C:\Program Files\1cv8\8.3.15.1830\bin\comcntr.dll"

Вместо указанной версии 8.3.15.1830 введите путь к вашей старой версии платформы, которая использовалась ранее.

4. Теперь зарегистрируем новую библиотеку comcntr.dll из папки актуальной платформы:

regsvr32 "C:\Program Files\1cv8\8.3.15.1830\bin\comcntr.dll"

После выполнения этой команды должно появиться системное сообщение об успешной регистрации модуля.

Важное примечание для 64-битных систем: Если сервер 1С:Предприятие у вас работает в 64-разрядном режиме, а Effector Saver запущен как 32-битное приложение (или наоборот), вам может потребоваться настроить службу компонентов COM+. Для этого выполним следующие действия:

1. Откроем службу компонентов Windows через меню Выполнить (сочетание клавиш Win+R) и введем команду dcomcnfg.
2. Перейдем в ветку Службы компонентов -> Компьютеры -> Мой компьютер -> Приложения COM+.
3. Если приложения V83COMConnector там нет, создадим его: нажмем правой кнопкой мыши по папке Приложения COM+ -> Создать -> Приложение. В мастере выберем "Создать новое приложение", дадим ему имя V83COMConnector и выберем тип "Серверное приложение".
4. В свойствах созданного приложения перейдем на вкладку Удостоверение и укажем системную учетную запись с правами администратора (например, учетную запись, от имени которой запускается служба сервера 1С).
5. Внутри приложения перейдем в папку Компоненты, нажмем правой кнопкой -> Создать -> Компонент. Укажем путь к зарегистрированному файлу comcntr.dll.

Шаг 2. Настройка параметров блокировки и кода разрешения в консоли 1С

Когда Effector Saver запускает процедуру резервного копирования, он должен наложить на базу данных временную блокировку, чтобы обычные пользователи не могли войти в систему во время создания бэкапа. Но самой программе резервного копирования доступ в базу должен оставаться открыт. Для этого используется так называемый Код разрешения.

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

1. Откроем утилиту Администрирование серверов 1С:Предприятия на сервере приложений.
2. В дереве консоли развернем ветку нашего кластера, перейдем в раздел Информационные базы и найдем целевую базу данных.
3. Откроем свойства этой базы. Обратим внимание на поле Код разрешения. Если оно пустое, это и есть причина, почему Effector Saver не может войти в базу под монопольной блокировкой.
4. Впишем в это поле уникальный секретный код. По умолчанию часто используют числовые значения, например 000000, или текстовые строки вроде BackupCode. Этот код будет служить ключом для обхода блокировки.
5. Нажмем кнопку ОК для сохранения параметров базы.

Шаг 3. Настройка параметров задачи в Effector Saver

Теперь нам необходимо передать этот секретный ключ программе резервного копирования, чтобы она могла беспрепятственно работать с заблокированной базой.

1. Запустим программу Effector Saver и откроем свойства нашей задачи резервного копирования.
2. Перейдем на вкладку Отключение пользователей (или аналогичный раздел настроек авторизации на сервере).
3. Установим флаг Принудительно завершать сеансы на сервере 1С:Предприятие.
4. Укажем параметры подключения к кластеру: адрес сервера, порт, имя администратора кластера и его пароль. Эти данные необходимы, так как отключение пользователей происходит через вызов административных функций сервера 1С.
5. В поле Код разрешения впишем то же самое значение, которое мы указали в консоли администрирования (например, 000000).
6. В параметрах подключения к самой информационной базе (строка соединения или дополнительные параметры запуска) добавим ключ запуска: /UC 000000. Именно этот ключ сообщает серверу, что запуск программы выполняется легитимно в обход установленной блокировки.

Проанализируем логику работы этой связки:

1. Effector Saver подключается к кластеру, используя права администратора сервера 1С.
2. Включает блокировку новых соединений с кодом разрешения 000000.
3. Принудительно завершает текущие активные сеансы пользователей на сервере.
4. Выполняет резервное копирование, подключаясь к базе с параметром запуска /UC 000000.
5. После завершения создания резервной копии снимает блокировку новых соединений, возвращая базу в рабочее состояние.

Шаг 4. Настройка автоматического завершения зависших сеансов

Иногда даже при полностью исправных COM-объектах и правильно настроенных кодах разрешения сеансы пользователей не закрываются. Это происходит из-за "зависания" сеансов на сервере приложений. Например, если пользователь некорректно выключил компьютер, отключился от терминала или у него временно оборвалась сеть, сервер 1С может продолжать считать этот сеанс активным. Такие "призрачные" сеансы могут препятствовать монопольной выгрузке базы.

Выясним, как автоматизировать борьбу с такими сеансами штатными средствами платформы 1С:

1. Запустим нужную информационную базу в режиме Конфигуратор от имени администратора.
2. Перейдем в главное меню: Администрирование -> Параметры информационной базы...
3. В открывшемся окне настроим следующие параметры:
• Время засыпания пассивного сеанса: установим значение в секундах, например 1200 (что соответствует 20 минутам). По истечении этого времени неактивный сеанс засыпает, освобождая занятые им лицензии.
• Время завершения спящего сеанса: установим значение 3600 (что соответствует 1 часу). Через час после перехода в спящий режим сервер полностью удалит сеанс из списка активных подключений.
4. Нажмем кнопку Применить и закроем Конфигуратор.

Благодаря этим настройкам, к моменту начала ночного резервного копирования сервер 1С самостоятельно очистит большую часть зависших и забытых пользователями сеансов, что существенно снизит нагрузку на механизмы принудительного отключения Effector Saver. Для решения этой задачи также подойдёт подсистема автоматического завершения неактивных сеансов.

Шаг 5. Диагностика специфических ошибок платформы

Если вы выполнили все вышеперечисленные шаги, но Effector Saver по-прежнему сообщает об ошибке при попытке отключить пользователей, причиной может быть известный баг самой платформы 1С:Предприятие. В некоторых релизах (особенно часто это проявлялось в ветках 8.3.15, 8.3.18 и 8.3.19) при обращении к серверным методам отключения пользователей через COM-соединение происходил критический сбой процесса.

В логах Effector Saver в этом случае может фигурировать ошибка вида:

Access violation... в модуле rtrsrvc.dll

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

Почему выгрузка в DT не является полноценным бэкапом?

Разберем важный комментарий одного из участников обсуждения: "выгрузка в dt это не бэкап". И это чистая правда. Выгрузка в файл с расширением .dt представляет собой логическое сжатие данных 1С, предназначенное в первую очередь для переноса базы между СУБД (например, из файлового режима в клиент-серверный или с MSSQL на PostgreSQL).

Проанализируем основные риски использования только выгрузок .dt:

• Ошибки логической целостности: Если в базе данных есть скрытые логические ошибки или повреждения таблиц, файл .dt может создаться без ошибок. Однако при попытке развернуть его на новом сервере платформа выдаст критическую ошибку, и вы останетесь без работающей базы.
• Отсутствие транзакционной согласованности: В отличие от бэкапов СУБД, выгрузка в .dt требует полной монопольной блокировки. На "живой" и активно работающей базе сделать ее корректно невозможно.

Рекомендация: Для надежного резервного копирования клиент-серверных баз настройте в Effector Saver создание резервных копий средствами СУБД (например, создание бэкапов через утилиту pg_dump для PostgreSQL или создание файлов .bak для Microsoft SQL Server). Выгрузку в .dt оставьте как дополнительный инструмент для архивации редких исторических срезов данных.

Заключение

Мы подробно разобрали, как восстановить корректную работу связки Effector Saver и сервера 1С:Предприятие после обновления платформы. Внимательно следите за регистрацией библиотеки comcntr.dll, всегда проверяйте актуальность кодов разрешения /UC в настройках баз данных и своевременно настраивайте автоматическое завершение спящих сеансов на сервере. Эти простые профилактические меры гарантируют стабильное создание резервных копий ваших баз данных каждую ночь.