Как исправить ошибку исключительной блокировки информационной базы при выгрузке в EffectorSaver?

Системный администратор 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

Проанализируем ситуацию, с которой часто сталкиваются системные администраторы при настройке автоматического резервного копирования. В программе EffectorSaver возникает ошибка: «Ошибка исключительной блокировки информационной базы. Активные сеансы и соединения», после чего процесс создания архива прерывается. Разберем по шагам, почему возникает эта проблема, и рассмотрим несколько надежных способов ее решения для файловых и серверных баз 1С.

Причина возникновения ошибки

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

Настройки EffectorSaver: как правильно завершать работу пользователей

В настройках задачи EffectorSaver есть штатные возможности для отключения сеансов. Посмотрим на них подробнее и выясним разницу:

  1. Завершить сеансы на сервере 1С:Предприятие: Данный вариант работает только для клиент-серверных баз. Механизм принудительно обрывает соединения непосредственно на уровне кластера серверов 1С. Для корректной работы этого метода необходимо указать учетные данные администратора кластера 1С (не путать с пользователем ИБ) и порт агента сервера (по умолчанию 1540). Также на сервере обязательно должна быть зарегистрирована компонента COM-соединения — comcntr.dll.
  2. Вызвать штатное завершение работы пользователей: Этот способ использует встроенные механизмы самой конфигурации 1С. Программа рассылает клиентским приложениям команду на закрытие. Метод подходит как для серверных, так и для файловых баз. Однако у него есть существенный минус: он не сработает, если у пользователя открыто модальное окно (например, вопрос о сохранении документа) или если приложение 1С зависло.

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

Решение для файловых баз 1С (через BAT-файлы)

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

Если пользователи работают локально на терминальном сервере, принудительно завершим все запущенные процессы 1С с помощью утилиты taskkill. Для этого добавим в bat-файл следующий код:


taskkill /im 1cv8* /f
timeout /t 10

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

net session /delete /y

Внимание: команда net session /delete /y обрывает все сетевые подключения к серверу, а не только сессии 1С. Используйте ее с осторожностью.

Альтернативные решения для клиент-серверных баз

Разберем надежные методы обеспечения бэкапа для серверного варианта работы, если штатное отключение через кластер не помогает.

1. Перезапуск службы сервера 1С

Перед выполнением резервного копирования можно использовать скрипт для жесткого перезапуска службы сервера 1С:Предприятие. Это гарантированно очистит базу от любых "зависших" подключений:


net stop "1C:Enterprise 8.3 Server Agent"
net start "1C:Enterprise 8.3 Server Agent"

2. Резервное копирование средствами СУБД (Рекомендуемый метод)

Выгрузка в файл .dt считается средством разработки и переноса баз, а не надежным инструментом регулярного бэкапа промышленных систем. Если база работает в связке с MS SQL Server или PostgreSQL, настоятельно рекомендуется перевести резервное копирование на уровень самой СУБД. Бэкапы через SQL выполняются "на горячую", не требуют монопольного доступа к базе и могут создаваться даже в моменты пиковой активности пользователей, полностью исключая ошибки исключительной блокировки.

← На главную