← На главную

При настройке автоматического резервного копирования информационных баз 1С (в частности, крупных конфигураций, таких как УПП) системные администраторы нередко сталкиваются со сбоем выполнения задачи и сообщением: «Ошибка исключительной блокировки информационной базы. Активные сеансы и соединения...». Проанализируем природу этой ошибки, выясним, почему традиционная выгрузка данных в файл .dt не подходит для регулярных бэкапов клиент-серверных баз, и разберем правильные методы организации резервного копирования.

Причина ошибки: монопольный доступ для выгрузки в dt

Рассмотрим, что происходит в момент запуска задачи резервного копирования средствами утилит вроде Effector Saver или скриптов пакетного запуска Конфигуратора с параметром /DumpIB. Для формирования файла выгрузки информационной базы платформе 1С:Предприятие требуется монопольный доступ. Если в момент старта задачи в базе присутствует хотя бы один активный сеанс (пользователь в режиме предприятия, фоновое задание или сеанс конфигуратора), операция аварийно завершается ошибкой блокировки.

Штатные механизмы завершения работы пользователей далеко не всегда могут корректно освободить базу:

1. Клиентское завершение сеансов: если у пользователя открыто модальное окно, диалог сохранения документа или сеанс завис на рабочей станции, клиентское приложение не закроется самостоятельно. Пользователи в режиме Конфигуратор также игнорируют команды штатного завершения.
2. Завершение сеансов на сервере: для принудительного разрыва соединений на уровне кластера сторонним утилитам требуются повышенные привилегии администратора кластера 1С, корректно зарегистрированная библиотека comcntr.dll либо настроенная служба администрирования RAS. При установке блокировки соединений необходимо передавать ключ разрешения запуска /UC <КодРазрешения>, иначе сам процесс выгрузки не сможет подключиться к заблокированной базе.

Почему нельзя использовать выгрузку в dt для регулярного бэкапа

Разберем фундаментальные технические ограничения формата .dt, из-за которых разработчики платформы не рекомендуют применять его для планового резервного копирования, особенно для клиент-серверных баз (SQL):

1. Назначение формата: файл выгрузки предназначен исключительно для конвертации данных между различными типами СУБД (например, переход с файловой базы на MS SQL Server, PostgreSQL) или для начального развертывания баз, но не для архивного хранения.
2. Проблемы с объемом и памятью: процесс выгрузки и последующей загрузки требует значительных ресурсов оперативной памяти. На тяжелых базах (характерно для производственных и учетных баз уровня УПП или ERP) этот процесс нередко завершается фатальной ошибкой нехватки памяти (Out of memory). Также возможны сбои при обработке отдельных таблиц размером более 4 ГБ.
3. Риск скрытой порчи данных: при наличии даже незначительных логических сбоев в исходных таблицах СУБД выгрузка в .dt может завершиться успешно, но восстановить базу обратно из полученного файла будет невозможно. Нативный бэкап СУБД в этом сценарии гарантирует целостность структуры.
4. Отсутствие восстановления на точку во времени: формат выгрузки делает слепок на один конкретный момент времени и не работает с журналами транзакций СУБД. Это исключает возможность восстановления состояния базы на произвольную минуту до сбоя.

Решение 1. Настройка штатного резервного копирования средствами СУБД (MS SQL)

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

Разберем по шагам типовой порядок действий в среде SQL Server Management Studio (SSMS):

1. Подключимся к экземпляру SQL Server с правами администратора.
2. Перейдем в раздел Управление (Management) и откроем Планы обслуживания (Maintenance Plans).
3. Запустим Мастер планов обслуживания (Maintenance Plan Wizard).
4. Зададим расписание выполнения: настроим создание полного резервного копирования (Full Backup) базы данных ночью, а в течение рабочего дня запланируем периодическое создание разностных бэкапов (Differential Backup) и архивацию журналов транзакций (Transaction Log) каждые 15–30 минут (для модели восстановления Full).
5. В списке задач выберем операцию Резервное копирование базы данных (Backup Database) и укажем целевую информационную базу 1С.
6. Настроим задачу очистки старых архивов (Maintenance Cleanup Task), чтобы предотвратить переполнение дискового пространства.

Если резервное копирование настраивается через специализированные программы (например, тот же Effector Saver), в них следует изменить вид задачи: вместо «Архивирование средствами 1С:Предприятие 8» необходимо выбрать «Архивирование средствами СУБД / MS SQL». В этом случае утилита отправляет нативные команды создания резервной копии напрямую в SQL Server без требования монопольного доступа к 1С.

Решение 2. Корректное завершение зависших сеансов и очистка серверного кэша

Если по организационным причинам временно требуется выгрузить базу именно средствами платформы, но сеансы остаются заблокированными из-за зависших «сеансов-призраков», выполним принудительную очистку сеансовых контекстов кластера 1С.

Выполним процедуру безопасной очистки кэша сеансов сервера:

1. Откроем оснастку служб операционной системы (services.msc) и остановим службу агента сервера: 1C:Enterprise 8.3 Server Agent (служба ragent).
2. Перейдем в каталог данных кластера серверов 1С (по умолчанию путь: C:\Program Files\1cv8\srvinfo).
3. Найдем каталог с идентификатором конкретного кластера (папка с длинным UID-именем) и внутри нее удалим только каталоги сеансовых контекстов, названия которых начинаются с префикса snccntx.
4. Обратите внимание: категорически запрещено удалять конфигурационные файлы кластера 1cv8wsrv.lst и 1CV8Reg.lst, так как это приведет к потере настроек кластера и списка зарегистрированных информационных баз.
5. Запустим службу агента сервера 1С заново. Зависшие соединения будут полностью сброшены.

Для предотвращения подобных ситуаций в будущем настроим параметры информационной базы в консоли администрирования кластера серверов 1С. Зададим свойства «Время засыпания пассивных сеансов» (например, 1200 секунд) и «Время завершения спящих сеансов» (например, 3600 секунд). В этом случае кластер 1С будет в автоматическом режиме удалять неактивные клиентские подключения в нерабочее время без участия администратора.