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

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

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

Ниже разобраны конкретные способы создания копии через SQL Server Management Studio и T-SQL, восстановление копии под новым именем для тестов, настройка автоматических бэкапов и контроль результата.

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

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

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

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

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

Узнайте точное имя базы данных в SQL Server: оно часто не совпадает с названием информационной базы в списке 1С. Имя можно посмотреть в консоли кластера 1С (свойства информационной базы, поле «База данных») или в списке баз в SQL Server Management Studio.

Определите модель восстановления базы: правый клик по базе в SSMS → «Свойства» → «Параметры». Для рабочих баз рекомендуется полная модель (Full) с регулярными бэкапами журнала транзакций — иначе журнал будет расти без ограничений. Для тестовых копий достаточно простой модели (Simple).

Способ 1: резервное копирование через SQL Server Management Studio

Самый наглядный способ — графический интерфейс SSMS. Подключитесь к серверу, раскройте узел «Базы данных», кликните правой кнопкой по нужной базе и выберите «Задачи» → «Создать резервную копию» (Tasks → Back Up). В открывшемся окне укажите тип копии «Полная» (Full), компонент «База данных» и путь к файлу назначения — по умолчанию предлагается каталог Backup в папке экземпляра SQL Server с расширением .bak.

На странице «Параметры носителя» рекомендуется включить проверку целостности резервной копии (Verify backup when finished) — это добавит времени, но сразу покажет, что файл читается. Если редакция SQL Server поддерживает сжатие, включите его на странице «Параметры резервного копирования» — файл получится заметно меньше.

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

1. 1
   Подключитесь к SQL Server в SSMS под учётной записью с правами на бэкап
2. 2
   Кликните правой кнопкой по базе 1С → Задачи → Создать резервную копию
3. 3
   Выберите тип «Полная», укажите путь к файлу .bak на диске с достаточным местом
4. 4
   Включите проверку целостности копии и при возможности сжатие
5. 5
   Нажмите ОК и дождитесь сообщения об успешном завершении
6. 6
   Скопируйте файл .bak на отдельный носитель или сетевое хранилище

Способ 2: копия скриптом T-SQL

Для автоматизации удобнее команда BACKUP DATABASE. Откройте новый запрос в SSMS и выполните скрипт, подставив имя своей базы и путь:

BACKUP DATABASE [TradeBase] TO DISK = N'D:\SQLBackup\TradeBase_full.bak' WITH COMPRESSION, CHECKSUM, INIT, NAME = N'Полная копия TradeBase';

Параметр COMPRESSION включает сжатие (если поддерживается редакцией), CHECKSUM добавляет контрольные суммы для выявления повреждений, INIT перезаписывает файл. Без INIT несколько бэкапов будут дописываться в один файл, что усложняет восстановление — для разовых копий удобнее один файл на один бэкап.

Чтобы запускать бэкап по расписанию, сохраните скрипт в файл .sql и вызывайте его через sqlcmd из планировщика задач Windows, либо создайте задание агента SQL Server (SQL Server Agent), если он доступен в вашей редакции. В Express-редакции агента нет, поэтому там остаётся только планировщик Windows с sqlcmd.

sqlcmd -S SERVERNAME -E -i D:\Scripts\backup_1c.sql -o D:\Scripts\backup_log.txt

Обязательно проверяйте код возврата и содержимое лога: задание планировщика может «успешно» выполняться, даже если бэкап не создался из-за нехватки места или прав. Регулярно открывайте файл лога и убеждайтесь, что размер .bak-файла меняется и соответствует размеру базы.

Как восстановить копию под новым именем (тестовая база)

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

Критически важный шаг — страница «Файлы»: по умолчанию SQL Server попытается восстановить файлы данных по старым путям рабочей базы, что приведёт либо к ошибке, либо к попытке перезаписи рабочих файлов. Измените пути файлов данных и журнала на новые, соответствующие тестовой базе. В T-SQL это делается параметром MOVE:

RESTORE DATABASE [TradeBase_Test] FROM DISK = N'D:\SQLBackup\TradeBase_full.bak' WITH MOVE N'TradeBase' TO N'D:\SQLData\TradeBase_Test.mdf', MOVE N'TradeBase_log' TO N'D:\SQLData\TradeBase_Test_log.ldf', REPLACE, RECOVERY;

Логические имена файлов для MOVE можно узнать командой RESTORE FILELISTONLY FROM DISK = 'путь к бэкапу'. После восстановления зайдите в консоль кластера 1С, создайте новую информационную базу, указав существующую базу данных SQL Server, либо скорректируйте параметры существующей тестовой записи. Перед первым запуском тестовой копии отключите в ней регламентные задания и обмены, чтобы тестовая база не начала отправлять реальные документы или письма.

Автоматизация и стратегия регулярных копий

Разовая копия не заменяет систему резервного копирования. Рабочая схема для базы в полной модели восстановления выглядит так: полный бэкап ежедневно в нерабочее время, разностные (дифференциальные) бэкапы несколько раз в день и бэкапы журнала транзакций каждые 15–60 минут в зависимости от допустимых потерь данных.

Организовать это можно через планы обслуживания (Maintenance Plans) в SSMS, через задания агента SQL Server с собственными скриптами или через сторонние утилиты бэкапа. Любой вариант должен включать ротацию файлов — удаление старых бэкапов по расписанию, иначе диск рано или поздно переполнится и бэкапы начнут молча падать.

Храните копии по правилу разнесения: хотя бы одна актуальная копия должна находиться вне сервера базы данных — на другом сервере, NAS или в облачном хранилище. Бэкапы на том же RAID-массиве защищают только от логических ошибок, но не от отказа оборудования или шифровальщика.

Проверка результата: как убедиться, что копия рабочая

Бэкап считается сделанным только тогда, когда подтверждено, что из него можно восстановиться. Минимальная проверка — команда RESTORE VERIFYONLY, которая проверяет читаемость и целостность файла без фактического восстановления. Она не гарантирует стопроцентную пригодность, но отлавливает большинство повреждений файла.

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

FAQ