Как правильно восстановить копию базы 1С из файла .bak в SQL Server без риска для рабочей базы?

Создание тестовой или аналитической копии базы данных из резервной копии рабочей системы — стандартная задача администратора 1С и СУБД. Однако при работе с графической консолью SQL Server Management Studio (SSMS) нередко возникает путаница с сопоставлением путей, логическими именами файлов и параметрами перезаписи. Разберем по шагам, как безопасно развернуть копию базы данных из архива .bak, не затронув продуктивный контур, и какие настройки необходимо выполнить на стороне 1С:Предприятия.

Разбираем назначение вкладки «Files» и опции «Relocate all files to folder»

В резервной копии .bak жестко прописаны пути к физическим файлам данных (.mdf/.ndf) и журнала транзакций (.ldf), в которых они находились в момент создания архива. Если восстанавливать резервную копию под новым именем базы без корректировки путей, SQL Server по умолчанию попытается положить файлы по старым адресам. Рассмотрим, к чему это может привести:

1. Если исходная рабочая база подключена и активна: SQL Server выдаст ошибку совместного доступа к файлу, так как рабочие файлы заняты процессом СУБД. В этом случае рабочая база будет аппаратно защищена от перезаписи, но восстановление копии прервется ошибкой.
2. Если рабочая база отключена (offline) или отсоединена (detach): SQL Server молча перезапишет физические файлы оригинала файлами из бэкапа, что приведет к потере актуальных данных рабочей базы.

Именно для исключения подобных ситуаций используется флажок «Relocate all files to folder» («Переместить все файлы в папку»). Когда мы устанавливаем этот параметр, SSMS автоматически перенаправляет создаваемые файлы в указанный каталог и формирует для них пути с учетом нового имени базы (или добавляет уникальные суффиксы). Если эта опция не используется, необходимо вручную проверить и скорректировать пути в таблице файлов в колонке «Restore As» («Восстановить как»), указав уникальные имена файлов, например: TestBase.mdf и TestBase_log.ldf.

Что происходит с логическими именами файлов (Logical File Name)

Проанализируем структуру файлов внутри базы данных. У каждого файла базы в SQL Server есть два имени:

1. Logical File Name (Логическое имя) — внутреннее системное имя файла, используемое сервером СУБД при выполнении команд и обращении к структуре базы.
2. Physical File Name (Физическое имя) — реальное имя файла на дисковой подсистеме сервера (например, D:\SQLData\Base_Data.mdf).

При восстановлении базы под новым именем логические имена файлов не изменяются автоматически. Они остаются точно такими же, какими были в исходной базе-источнике бэкапа. Это нормальное штатное поведение SQL Server. Несовпадение логического имени файла с именем базы никак не влияет на производительность и стабильность работы «1С:Предприятия». Если по соображениям эстетики или регламентов компании требуется привести логические имена в соответствие с новым именем базы, выполним следующую команду в окне запросов SSMS:

USE [master];
ALTER DATABASE [ИмяБазыКопии] 
MODIFY FILE (NAME = N'СтароеЛогическоеИмя_Data', NEWNAME = N'НовоеЛогическоеИмя_Data');
ALTER DATABASE [ИмяБазыКопии] 
MODIFY FILE (NAME = N'СтароеЛогическоеИмя_Log', NEWNAME = N'НовоеЛогическоеИмя_Log');

Параметры вкладки «Options» (Параметры)

На вкладке параметров при восстановлении в уже существующую пустую или тестовую базу критически важно обратить внимание на два пункта:

1. Overwrite the existing database (WITH REPLACE): этот флаг сообщает SQL Server, что мы осознанно разрешаем затереть существующую базу данных приемника. Если база-приемник уже была предварительно создана в дереве SSMS, без этой галочки процесс завершится ошибкой валидации метаданных. Если же имя новой базы введено впервые и базы с таким именем еще нет на сервере, ставить этот флаг не обязательно.
2. Close existing connections to destination database: обязательный параметр при перезаписи существующей тестовой базы. Если к базе подключен сервер приложений «1С:Предприятия» или фоновый процесс, SQL Server выдаст ошибку эксклюзивного доступа. Установка этой опции автоматически переводит базу в режим SINGLE_USER WITH ROLLBACK IMMEDIATE, принудительно сбрасывает все сеансы и позволяет выполнить операцию.

Пошаговый алгоритм восстановления базы через графический интерфейс SSMS

Сведем правильную последовательность действий в единую инструкцию:

1. В окне Object Explorer щелкнем правой кнопкой мыши по узлу Databases и выберем Restore Database...
2. На вкладке General в блоке Source переключимся на Device, выберем нужный файл .bak.
3. В поле Database блока Destination укажем точное имя нашей новой (тестовой) базы данных.
4. Перейдем на вкладку Files. Установим флажок «Relocate all files to folder» либо в таблице ниже в колонке «Restore As» вручную зададим новые пути и имена для файлов данных (.mdf) и журнала (.ldf), чтобы они не пересекались с рабочей базой.
5. Перейдем на вкладку Options. Отметим галочками «Overwrite the existing database (WITH REPLACE)» (если база уже создана) и «Close existing connections to destination database».
6. Нажмем OK и дождемся успешного завершения операции.

Альтернативный вариант: выполнение операции с помощью T-SQL

Использование T-SQL скрипта полностью исключает ошибки интерфейса и наглядно фиксирует перенаправление файлов. Выполним восстановление через скрипт по шагам:

1. Определим точные логические имена файлов внутри бэкапа:

RESTORE FILELISTONLY FROM DISK = N'D:\Backup\WorkBase.bak';

2. Сбросим соединения с тестовой базой и выполним накат бэкапа с явным перемещением файлов опцией MOVE:

USE [master];
-- Если база уже существовала, сбрасываем сеансы
IF DB_ID('TestBase') IS NOT NULL
    ALTER DATABASE [TestBase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

RESTORE DATABASE [TestBase]
FROM DISK = N'D:\Backup\WorkBase.bak'
WITH 
    MOVE N'WorkBase_Data' TO N'D:\SQLData\TestBase.mdf',
    MOVE N'WorkBase_Log'  TO N'D:\SQLLog\TestBase_log.ldf',
    REPLACE,
    RECOVERY;

-- Возвращаем многопользовательский режим
ALTER DATABASE [TestBase] SET MULTI_USER;

Оптимизация копии: перевод в Simple Recovery Model

Рабочие базы «1С:Предприятия» чаще всего функционируют в модели восстановления Full (Полная) для возможности восстановления на точку во времени. Развернутая из бэкапа тестовая база наследует эту модель. Если в тестовой базе не настроено регулярное резервное копирование журнала транзакций, файл .ldf быстро разрастется и займет все свободное дисковое пространство. Сразу после восстановления переведем копию в простую модель восстановления:

ALTER DATABASE [TestBase] SET RECOVERY SIMPLE;

Критические действия в «1С:Предприятии» после развертывания копии

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

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