Как развернуть копию базы 1С на SQL Server

Развертывание копии базы 1С на SQL Server — стандартная задача администратора: она нужна для создания тестовой среды, проверки обновлений перед установкой в рабочую базу, анализа данных без риска повредить продуктив и обучения пользователей на реальных данных. В отличие от файлового варианта, где достаточно скопировать файл 1Cv8.1CD, в клиент-серверной архитектуре копирование выполняется средствами СУБД с последующей регистрацией базы в кластере 1С или в списке информационных баз.

Процедура состоит из трёх этапов: получение резервной копии на уровне SQL Server, восстановление её под новым именем и подключение восстановленной базы к платформе 1С. Каждый этап имеет свои подводные камни — от нехватки прав учётной записи до конфликта имён баз в кластере. Ниже разобраны все шаги с проверками результата и типичными ошибками.

Когда нужна копия базы и какой способ выбрать

Существует два принципиально разных подхода к получению копии базы 1С. Первый — выгрузка информационной базы в файл .dt через конфигуратор. Второй — резервное копирование средствами SQL Server с последующим восстановлением. Для больших баз (десятки и сотни гигабайт) выгрузка в .dt занимает часы и требует монопольного доступа, поэтому на практике для SQL-баз почти всегда используют второй способ.

Копия через SQL Server создаётся быстро, не требует остановки работы пользователей (при использовании полной модели восстановления и осторожном планировании) и сохраняет данные на момент создания бэкапа. Ограничение: восстанавливать базу нужно на тот же или совместимый экземпляр SQL Server, а версия СУБД целевого сервера не должна быть ниже версии источника.

Подготовка: что проверить перед началом

Перед созданием копии убедитесь, что у вас есть необходимые права. Для создания резервной копии достаточно роли db_backupoperator в исходной базе, для восстановления новой базы — права dbcreator или sysadmin на уровне экземпляра SQL Server. Если копию будет регистрировать другой специалист, заранее согласуйте имя новой базы: оно должно быть уникальным и на экземпляре SQL Server, и в кластере 1С.

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

Создание резервной копии исходной базы

Откройте SQL Server Management Studio (SSMS), подключитесь к экземпляру с рабочей базой. В обозревателе объектов найдите нужную базу, щёлкните правой кнопкой и выберите «Задачи» → «Создать резервную копию». Укажите тип копии «Полная», задайте путь к файлу .bak на диске с достаточным объёмом и запустите операцию.

Альтернатива графическому интерфейсу — команда T-SQL, которую удобно сохранить как скрипт для регулярного использования. Она же позволяет автоматизировать процесс через планировщик.

BACKUP DATABASE [Trade_Base] TO DISK = N'D:\Backup\Trade_Base_copy.bak' WITH COPY_ONLY, COMPRESSION, CHECKSUM;

Параметр COPY_ONLY важен, если на базе настроено регулярное резервное копирование: такой бэкап не нарушает цепочку разностных копий и не влияет на штатный план обслуживания. COMPRESSION уменьшает размер файла (доступно не во всех редакциях SQL Server), CHECKSUM добавляет проверку целостности при чтении.

Восстановление копии под новым именем

В SSMS щёлкните правой кнопкой по узлу «Базы данных» и выберите «Восстановить базу данных». В качестве источника укажите «Устройство» и путь к файлу .bak. В поле «Назначение» впишите новое имя базы — например, Trade_Base_Test. Обязательно проверьте вкладку «Файлы»: физические имена файлов .mdf и .ldf должны быть уникальными, иначе восстановление попытается перезаписать файлы рабочей базы.

Ту же операцию можно выполнить скриптом. Предварительно узнайте логические имена файлов внутри бэкапа командой RESTORE FILELISTONLY, затем выполните восстановление с параметром MOVE.

RESTORE FILELISTONLY FROM DISK = N'D:\Backup\Trade_Base_copy.bak';
RESTORE DATABASE [Trade_Base_Test] FROM DISK = N'D:\Backup\Trade_Base_copy.bak'
WITH MOVE N'Trade_Base' TO N'D:\SQLData\Trade_Base_Test.mdf',
MOVE N'Trade_Base_log' TO N'D:\SQLData\Trade_Base_Test_log.ldf', RECOVERY;

После завершения восстановления убедитесь, что база находится в состоянии ONLINE и доступна для запросов. Если база осталась в состоянии Restoring — скорее всего, был указан параметр NORECOVERY вместо RECOVERY, выполните RESTORE DATABASE с RECOVERY повторно без восстановления данных.

Регистрация копии в кластере 1С

Восстановленная база SQL сама по себе ещё не доступна пользователям 1С — её нужно зарегистрировать в кластере серверов 1С:Предприятия. Откройте консоль управления серверами 1С, разверните нужный кластер, перейдите в «Информационные базы» и создайте новую базу. Укажите имя (оно будет отображаться в списке у пользователей), тип СУБД MS SQL Server, имя экземпляра SQL Server и имя восстановленной базы — Trade_Base_Test.

Ключевой момент: снимите флаг «Создать базу данных в случае её отсутствия» или следите, чтобы имя базы данных точно совпадало с восстановленной. Если оставить флаг и ошибиться в имени, платформа создаст рядом пустую базу, и вы подключите пользователей к пустышке. Учётная запись, указанная для доступа к СУБД, должна иметь права владельца (db_owner) на восстановленную базу.

1. 1
   Создайте полную резервную копию рабочей базы в SSMS с параметром COPY_ONLY
2. 2
   Восстановите бэкап под новым именем, проверив уникальность имён файлов .mdf и .ldf
3. 3
   Убедитесь, что восстановленная база в состоянии ONLINE
4. 4
   Зарегистрируйте новую информационную базу в консоли кластера 1С без создания новой БД
5. 5
   Зайдите в копию конфигуратором и отключите регламентные задания
6. 6
   Проверьте вход пользователем и работу ключевых отчётов

Отключение регламентных заданий и опасных настроек

Копия рабочей базы наследует все настройки обменов, регламентных заданий и подключений к внешним системам. Если этого не предотвратить, тестовая база начнёт отправлять реальные данные: выгружать заказы на сайт, обмениваться с банком, рассылать письма контрагентам, синхронизироваться с другими учётными системами. Последствия — от дублирования документов до финансовых ошибок.

Стандартный приём — сразу после восстановления запустить в копии обработку, которая отключает регламентные задания, либо воспользоваться встроенным механизмом: при создании информационной базы в кластере можно установить параметр «Блокировка регламентных заданий включена». Дополнительно проверьте настройки обменов, FTP-подключений, адресов веб-сервисов и учётных записей почты внутри конфигурации.

Проверка результата и обслуживание копии

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

Учтите, что копия занимает дисковое пространство и потребляет ресурсы сервера. Если тестовая база нужна временно — например, для проверки обновления — запланируйте её удаление после завершения работ. Для регулярно обновляемых тестовых сред имеет смысл написать скрипт, который выполняет весь цикл (бэкап, восстановление, отключение заданий) автоматически по расписанию.

Частые вопросы