При обслуживании информационных баз 1С часто возникает необходимость развернуть резервную копию продуктивной базы на том же сервере для целей тестирования, разработки или обновления конфигурации. Однако администраторы регулярно сталкиваются с ситуацией, когда SQL Server Management Studio (SSMS) вместо разворачивания в новую базу пытается восстановить данные поверх существующей рабочей базы. В результате процесс прерывается ошибкой: «Сбой при попытке получения монопольного доступа к базе данных» (Exclusive access could not be obtained), либо возникает риск случайной перезаписи продуктивных данных.
Проанализируем причины такого поведения СУБД, выясним технические нюансы работы графического интерфейса SSMS и разберем по шагам правильные и безопасные способы клонирования базы данных.
Почему MS SQL пытается восстановить бэкап в рабочую базу
Выясним причину ошибки монопольного доступа. Корни этой проблемы кроются в механизме считывания метаданных резервной копии:
Чтение заголовка файла резервной копии: При указании файла .bak среда SSMS автоматически считывает заголовок бэкапа, извлекая оригинальное имя базы-источника, а также исходные физические пути к файлам данных (.mdf, .ndf) и журнала транзакций (.ldf).
Автоматический сброс введенных настроек: Если вы сначала создали пустую базу или ввели новое имя в поле назначения, а затем указали файл бэкапа, графический мастер восстановления часто автоматически перезаписывает имя базы и пути к файлам на оригинальные.
Конфликт занятых файлов: Рабочая база данных постоянно открыта процессами сервера «1С:Предприятие». Поскольку мастер восстановления пытается записать данные в оригинальные файлы работающей базы, SQL Server не может получить к ним монопольный доступ и блокирует операцию.
Предварительное создание пустой базы: В MS SQL 2012 и выше предварительное создание пустой базы через консоль не требуется. Созданная пустая база уже занимает физические файлы на диске и удерживает их дескрипторы, что создает лишние конфликты блокировок.
Пошаговое восстановление через графический интерфейс SSMS
Разберем правильный порядок действий при восстановлении базы под новым именем через Management Studio без предварительного создания пустой базы-приемника.
Откроем SQL Server Management Studio и подключимся к нужному экземпляру.
В обозревателе объектов (Object Explorer) нажмем правой кнопкой мыши непосредственно на папку Базы данных (Databases) и выберем пункт меню Восстановить базу данных... (Restore Database...).
В открывшемся окне в разделе источника переключим переключатель на Устройство (Device), нажмем кнопку выбора и укажем путь к файлу резервной копии .bak.
Обратим внимание на раздел назначения (Destination): поле База данных (Database) автоматически заполнится старым именем. Введем здесь вручную совершенно новое имя (например, Test1).
Перейдем на вкладку Файлы (Files). Это критически важный шаг. Убедимся, что пути в столбце «Восстановить как» (Restore As) ведут к новым файлам, а не к рабочей базе. Рекомендуется установить флаг Переместить все файлы в папку (Relocate all files to folder) или вручную скорректировать имена файлов на диске (например, заменить source.mdf на Test1.mdf и source_log.ldf на Test1_log.ldf).
Перейдем на вкладку Параметры (Options). Если целевая база уже существовала и ее нужно обновить, установим флаг Перезаписать существующую базу данных (WITH REPLACE). Также полезно отметить пункт Закрыть существующие соединения с целевой базой данных (Close existing connections to destination database), чтобы разорвать фоновые сеансы.
Нажмем кнопку ОК и дождемся завершения процесса.
Надежный способ восстановления с помощью скрипта T-SQL
Использование скриптов Transact-SQL исключает ошибки графического интерфейса, гарантирует полный контроль над процессом и позволяет автоматизировать процедуру. Рассмотрим подробнее, как восстановить базу с переопределением путей.
Сначала определим точные логические имена файлов, сохраненные внутри резервной копии:
RESTORE FILELISTONLY
FROM DISK = 'C:\Backup\source_base.bak';
В результирующей таблице обратим внимание на значения в колонке LogicalName для строк с типами D (Data) и L (Log).
Теперь выполним восстановление с явным указанием новых физических путей через конструкцию MOVE ... TO ...:
RESTORE DATABASE [Test1]
FROM DISK = 'C:\Backup\source_base.bak'
WITH
MOVE 'Source_Logical_Data' TO 'D:\SQLData\Test1.mdf',
MOVE 'Source_Logical_Log' TO 'L:\SQLLog\Test1_log.ldf',
RECOVERY,
REPLACE,
STATS = 10;
Параметр MOVE связывает внутреннее логическое имя файла данных и лога из бэкапа с новыми физическими файлами на сервере, исключая перезапись оригинальной рабочей базы.
Особенности настройки базы данных для «1С:Предприятия»
После успешного разворачивания копии базы на уровне СУБД необходимо правильно подготовить ее для работы с сервером «1С:Предприятия»:
Исправление «осиротевших» пользователей (Orphaned Users): Если база 1С подключается к СУБД под отдельной учетной записью (а не под учетной записью системного администратора sa), идентификатор пользователя (SID) внутри восстановленной базы может не совпасть с логином на сервере. Для восстановления связи выполним команду:
USE [Test1];
ALTER USER [ИмяПользователя1С] WITH LOGIN = [ИмяПользователя1С];
Блокировка регламентных заданий: При регистрации созданной копии в консоли администрирования кластера серверов 1С обязательно сразу откроем свойства информационной базы и установим флаг «Блокировка регламентных заданий включена», а также зададим период блокировки. Если этого не сделать, тестовая база сразу начнет выполнять регламентные задания рабочей базы: отправку почты клиентам, выгрузку накладных, синхронизацию с банками и обмен данными с внешними системами.
Блокировка сеансов: На этапе первоначальной настройки копии рекомендуется также установить флаг «Блокировка начала сеансов включена», чтобы предотвратить случайный вход пользователей до того, как администратор отключит внешние интеграции и веб-сервисы.
Соблюдение данного порядка действий гарантирует безопасное разворачивание копий баз данных без угрозы остановки работы основного продуктивного контура.