В процессе сопровождения клиент-серверных информационных баз 1С:Предприятие регулярно возникает необходимость развернуть свежую резервную копию рабочей базы в тестовую или аналитическую среду. Однако при выполнении стандартной процедуры восстановления через среду SQL Server Management Studio (SSMS) администраторы нередко сталкиваются с ситуацией, когда СУБД начинает требовать монопольный доступ к рабочей базе-источнику, блокирует активные сеансы пользователей или завершает процесс восстановления с ошибкой.
Разберем причины возникновения такого поведения, выясним, какие параметры мастера восстановления приводят к блокировкам, и рассмотрим правильные варианты создания копии как через графический интерфейс, так и с помощью сценариев T-SQL.
Когда мы разворачиваем бэкап из файла формата .bak в новую базу данных, исходная рабочая база теоретически вообще не должна участвовать в процессе: данные считываются напрямую из архивного файла. Ошибки и попытки монопольного захвата исходной базы возникают по двум основным причинам:
WITH NORECOVERY). Этот механизм предназначен для сценариев аварийного восстановления текущей рабочей базы при сбое, но при разворачивании тестовой копии он ошибочно пытается перевести действующую рабочую базу в режим RESTORING, требуя закрытия всех активных соединений 1С..mdf и .ldf, которые использовались на момент создания архива. Если при восстановлении явно не указать новые имена и каталоги для тестовой базы, SQL Server попытается перезаписать рабочие файлы базы-источника, которые уже открыты и монопольно удерживаются службой СУБД.Рассмотрим правильную последовательность действий в мастере восстановления среды SQL Server Management Studio, которая гарантирует изоляцию процесса от рабочей базы.
.bak. В поле назначения (Destination Database) обязательно указываем имя базы-приемника (например, BGU_Test).BGU_Test.mdf и BGU_Test_log.ldf). Это предотвратит попытку перезаписи файлов рабочей базы.Использование прямого T-SQL скрипта полностью исключает влияние скрытых настроек графического интерфейса SSMS и снижает вероятность человеческой ошибки. Проанализируем, как правильно сформировать такой запрос.
Для начала выясним точные логические имена файлов, хранящихся внутри архива. Выполним команду:
RESTORE FILELISTONLY
FROM DISK = N'C:\Backup\BGU_backup.bak';
В выводе запроса обратим внимание на значения в колонке LogicalName для строк с типом D (данные) и L (журнал транзакций). Затем выполним команду восстановления с явным перенаправлением файлов (параметр MOVE):
USE [master];
GO
-- Переводим только тестовую базу в однопользовательский режим для разрыва старых сеансов
IF DB_ID('BGU_Test') IS NOT NULL
BEGIN
ALTER DATABASE [BGU_Test] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
END
GO
-- Выполняем восстановление
RESTORE DATABASE [BGU_Test]
FROM DISK = N'C:\Backup\BGU_backup.bak'
WITH
MOVE N'BGU2_Data' TO N'D:\SQLData\BGU_Test.mdf',
MOVE N'BGU2_Log' TO N'D:\SQLData\BGU_Test_log.ldf',
REPLACE,
RECOVERY;
GO
-- Возвращаем тестовую базу в многопользовательский режим
ALTER DATABASE [BGU_Test] SET MULTI_USER;
GO
Такой скрипт работает полностью автономно, не затрагивает рабочую базу и может быть встроен в расписание Агента SQL Server (SQL Server Agent) для регулярного автоматического обновления тестового контура.
При работе с клиент-серверными базами 1С важно учитывать ряд ограничений и настроек безопасности:
Администрирование → Обслуживание → Резервное копирование и восстановление разработан исключительно для файловых информационных баз. В клиент-серверном варианте создание дампов должно осуществляться средствами СУБД (планы обслуживания MS SQL)..dt через Конфигуратор не рекомендуется в качестве регулярного бэкапа для больших баз, так как требует монопольной блокировки информационной базы и предназначено в первую очередь для миграции между различными СУБД (например, с MS SQL на PostgreSQL).