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

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

Основной инструмент — SQL Server Management Studio (SSMS) или прямые команды T-SQL. Оба подхода дают одинаковый результат, но скрипты удобнее для автоматизации и повторяемых операций. Ниже разобраны три рабочих способа: резервное копирование с восстановлением (backup/restore), отсоединение и присоединение файлов (detach/attach) и копирование через мастер Copy Database, а также проверка результата и типичные ошибки.

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

Когда копия через SQL предпочтительнее выгрузки .dt

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

Копирование через СУБД оправдано в типовых ситуациях: подготовка тестовой базы для проверки обновления конфигурации, перенос базы на другой SQL-сервер, создание «снимка» перед рискованной операцией (свертка, массовая загрузка данных), организация резервного копирования по расписанию. Для файловых баз 1С этот способ неприменим — там копируется просто файл 1Cv8.1CD.

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

Перед началом убедитесь, что у вас есть достаточные права: для backup/restore нужна роль sysadmin на SQL Server или членство в db_owner/db_backupoperator на исходной базе плюс права на создание базы. Также проверьте свободное место на диске — файл резервной копии и файлы новой базы потребуют объёма, сопоставимого с размером исходной базы.

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

Узнайте физические имена и пути файлов исходной базы — они понадобятся для параметра WITH MOVE при восстановлении. Это можно сделать запросом к системному представлению sys.master_files или в свойствах базы в SSMS на вкладке «Файлы».

SELECT name, physical_name, type_desc FROM sys.master_files WHERE database_id = DB_ID('ИмяБазы');

Способ 1: копия через резервное копирование и восстановление

Это основной и самый безопасный метод. Сначала создаётся полная резервная копия рабочей базы в файл .bak, затем этот файл восстанавливается под новым именем. Исходная база при этом продолжает работать, пользователи не отключаются.

Ключевой момент — параметр WITH MOVE. Файлы данных нельзя восстановить поверх существующих файлов исходной базы, поэтому каждому логическому файлу указывается новый физический путь. Логические имена файлов берутся из вывода команды RESTORE FILELISTONLY или из запроса к sys.master_files, показанного выше.

1. 1
   Создайте резервную копию: BACKUP DATABASE [ИсходнаяБаза] TO DISK = 'D:\Backup\copy.bak' WITH COPY_ONLY, COMPRESSION
2. 2
   Посмотрите логические имена файлов: RESTORE FILELISTONLY FROM DISK = 'D:\Backup\copy.bak'
3. 3
   Восстановите копию: RESTORE DATABASE [ТестоваяБаза] FROM DISK = 'D:\Backup\copy.bak' WITH MOVE 'ЛогичИмяДанных' TO 'D:\Data\Test.mdf', MOVE 'ЛогичИмяЖурнала' TO 'D:\Data\Test.ldf'
4. 4
   Дождитесь сообщения об успешном восстановлении и проверьте, что база в состоянии ONLINE
5. 5
   Зарегистрируйте копию в списке баз 1С и отключите в ней регламентные задания

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

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

Метод заключается в отсоединении базы от сервера, копировании файлов .mdf и .ldf средствами операционной системы и присоединении обеих баз обратно. Он быстрее backup/restore на очень больших базах, так как не тратит время на чтение и упаковку данных в бэкап, но требует полной остановки работы с базой на время отсоединения.

Перед отсоединением переведите базу в однопользовательский режим с принудительным завершением соединений (WITH ROLLBACK IMMEDIATE), иначе команда detach завершится ошибкой из-за активных сессий. После копирования файлов присоедините исходную базу обратно, а затем присоедините скопированные файлы под новым именем базы.

После attach скопированных файлов под новым именем проверьте владельца базы (параметр AUTHORIZATION) и сопоставление пользователей — при переносе между серверами логины могут не совпасть, и пользователи базы станут «осиротевшими». Это исправляется пересозданием логина или процедурой сопоставления.

Способ 3: мастер Copy Database Wizard

Для разового переноса базы между двумя SQL-серверами удобен графический мастер Copy Database Wizard в SSMS. Он запускается из контекстного меню базы (Задачи → Копировать базу данных) и предлагает два режима: detach/attach либо объект SMO, который копирует базу без её остановки, но медленнее.

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

Регистрация копии в 1С и защита от «побочных эффектов»

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

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

Проверка результата и контроль целостности

После восстановления убедитесь, что база находится в состоянии ONLINE и доступна для чтения. Затем выполните проверку целостности командой DBCC CHECKDB — на больших базах она занимает заметное время, но гарантирует, что копия не содержит повреждений, особенно если источником был detach/attach или копирование файлов.

Финальная проверка — вход в копию через клиент 1С под учётной записью администратора: откройте несколько типовых документов и отчётов, сравните итоговые цифры (например, оборотно-сальдовую ведомость) с рабочей базой на дату копирования. Совпадение контрольных сумм — признак корректной копии.

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