Как скопировать базу 1С средствами SQL

Копирование базы 1С через СУБД — стандартный способ развернуть тестовую копию рабочей базы, перенести данные на другой сервер или создать резервную копию перед обновлением. В отличие от выгрузки в .dt через конфигуратор, копирование средствами SQL выполняется быстрее и не требует монопольного доступа на длительное время, но предъявляет более строгие требования к правам и аккуратности.

Основной метод — создание резервной копии (backup) базы данных на уровне SQL Server и её восстановление (restore) под новым именем. Альтернатива — отключение базы (detach) с копированием файлов данных и журнала. Оба подхода работают с Microsoft SQL Server, под PostgreSQL логика аналогична, но команды другие.

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

Когда копирование через SQL подходит, а когда нет

Копирование средствами СУБД оправдано, если база большая (десятки гигабайт и больше), выгрузка в .dt занимает часы или завершается ошибкой, а также когда нужна точная побитовая копия для воспроизведения проблемы на тестовом стенде. Ещё один типичный сценарий — перенос базы на другой SQL-сервер при миграции инфраструктуры.

Метод не подходит, если нужно перенести данные между разными СУБД (например, с MS SQL на PostgreSQL) — физические файлы несовместимы. Также он бесполезен, когда требуется «очистить» базу от истории или перенести только часть данных: SQL-копия всегда полная. В этих случаях используют выгрузку .dt, обмен через XML или специализированные обработки переноса данных.

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

Перед началом убедитесь, что у учётной записи есть права на создание резервных копий (роль db_backupoperator или выше) и на восстановление баз (dbcreator или sysadmin). Проверьте свободное место на диске: файл резервной копии несжатой базы примерно равен размеру данных, а при восстановлении потребуется ещё столько же под файлы новой базы.

Узнайте точное имя базы данных в SQL Server — оно не всегда совпадает с именем информационной базы в списке 1С. Имя видно в свойствах базы в консоли кластера 1С или в списке баз в SQL Server Management Studio (SSMS). Заодно выясните, где физически лежат файлы данных (.mdf) и журнала (.ldf): при восстановлении под новым именем пути придётся указать явно, иначе можно перезаписать файлы рабочей базы.

Способ 1: копирование через Backup и Restore

Это рекомендуемый способ, поскольку исходная база продолжает работать в обычном режиме. Резервное копирование не блокирует пользователей надолго и не требует завершения сеансов 1С.

Откройте SQL Server Management Studio, подключитесь к серверу, найдите базу в обозревателе объектов. Щёлкните по ней правой кнопкой: «Задачи» → «Создать резервную копию». Тип копии — «Полная», назначение — «Диск», укажите путь к файлу .bak. Для ускорения и экономии места можно включить сжатие резервной копии в параметрах.

После завершения копирования восстановите копию: правой кнопкой по узлу «Базы данных» → «Восстановить базу данных». Источник — «Устройство», укажите созданный .bak-файл. В поле «База данных назначения» введите новое имя, например Base_Test. На вкладке «Файлы» обязательно измените пути и имена .mdf и .ldf на новые. На вкладке «Параметры» снимите флажок «Сохранить параметры репликации», если он активен, и при необходимости включите «Закрыть существующие соединения» — для новой базы это не критично.

1. 1
   Проверьте свободное место и права учётной записи на SQL Server
2. 2
   Создайте полную резервную копию рабочей базы в файл .bak
3. 3
   Запустите восстановление с новым именем базы
4. 4
   На вкладке «Файлы» задайте новые пути для .mdf и .ldf
5. 5
   Дождитесь завершения restore и проверьте, что база в состоянии Online
6. 6
   Зарегистрируйте копию в консоли кластера 1С или подключите к ней конфигуратор

Те же действия можно выполнить скриптом T-SQL — это удобно для регулярных копирований:

BACKUP DATABASE [Base_Work]
TO DISK = N'D:\SQLBackup\Base_Work_copy.bak'
WITH COMPRESSION, INIT;
GO

RESTORE DATABASE [Base_Test]
FROM DISK = N'D:\SQLBackup\Base_Work_copy.bak'
WITH MOVE N'Base_Work'     TO N'D:\SQLData\Base_Test.mdf',
MOVE N'Base_Work_log' TO N'D:\SQLData\Base_Test_log.ldf',
REPLACE;
GO

Логические имена файлов в предложении MOVE должны точно совпадать с именами исходной базы — их можно посмотреть запросом SELECT name, physical_name FROM sys.master_files WHERE database_id = DB_ID('Base_Work').

Способ 2: Detach, копирование файлов, Attach

Этот способ быстрее на очень больших базах, так как не тратится время на формирование .bak, но требует остановки базы: все сеансы 1С должны быть завершены. В SSMS: правой кнопкой по базе → «Задачи» → «Отсоединить», отметьте «Удалить соединения» и при необходимости «Обновить статистику».

После отсоединения скопируйте файлы .mdf и .ldf в новый каталог средствами операционной системы. Затем присоедините исходную базу обратно («Присоединить» на узле «Базы данных» с указанием исходного .mdf) — рабочая база вернётся в строй. Скопированные файлы присоедините под новым именем: в мастере присоединения укажите скопированный .mdf и измените имя базы в поле «Присоединить как».

CREATE DATABASE [Base_Test] ON (FILENAME = N'D:\SQLCopy\Base_Test.mdf'), (FILENAME = N'D:\SQLCopy\Base_Test_log.ldf') FOR ATTACH;

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

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

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

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

Проверка результата и ограничения метода

После восстановления проверьте состояние базы в SSMS: она должна быть Online, без пометок Restoring или Suspect. Затем запустите конфигуратор или тонкий клиент 1С, подключившись к новой информационной базе, и убедитесь, что открываются справочники и документы, а даты последних документов соответствуют моменту создания копии.

Дополнительная проверка — запрос копий ключевых таблиц: сравните количество строк в основных таблицах документов рабочей базы и копии. Полное совпадение означает, что копия целостна на момент backup.

Учтите ограничения: восстановить базу можно только на SQL Server той же или более новой версии. Копия, снятая в момент активной работы пользователей, консистентна на уровне транзакций SQL, но бизнес-логически может содержать незавершённые операции — для критичных тестов лучше делать копию в нерабочее время.

Альтернативы и частные сценарии

Копирование на PostgreSQL

На PostgreSQL используют связку pg_dump и pg_restore либо копирование через создание базы из шаблона: CREATE DATABASE base_test TEMPLATE base_work; — при условии, что к исходной базе нет активных подключений. После копирования базу так же регистрируют в консоли кластера 1С с указанием типа СУБД PostgreSQL.

Регулярное обновление тестовой копии

Если тестовую копию нужно обновлять регулярно, автоматизируйте связку backup/restore скриптом T-SQL через задание SQL Server Agent или планировщик Windows с sqlcmd. Перед восстановлением завершайте сеансы 1С на тестовой базе через консоль кластера, иначе restore не сможет получить монопольный доступ.

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