Как снять бэкап базы 1С в MS SQL и развернуть его как отдельную информационную базу

Копию базы 1С средствами SQL Server делают в три шага: BACKUP DATABASE ... WITH COPY_ONLY на рабочей базе, RESTORE DATABASE ... WITH MOVE в базу с новым именем и регистрация этой базы в кластере 1С с включённой блокировкой регламентных заданий. Пользователей выгонять не нужно: в отличие от выгрузки .dt через Конфигуратор, бэкап SQL снимается на ходу и не требует монопольного режима.

Способ выручает, когда база весит десятки гигабайт и выгрузка .dt идёт часами, а копия нужна сегодня: для теста обновления, для разработчика, для разбора ошибки. Ниже — команды T-SQL, которые можно вставить в SQL Server Management Studio (SSMS) и запустить, подставив свои имена.

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

Пять минут проверки избавят от ошибки на середине восстановления.

• 💾 Место на диске. Под файл бэкапа нужно примерно 30–60% от размера базы при сжатии и около 100% без него. Под восстановленную копию — столько же, сколько занимают файлы данных и журнала рабочей базы, включая их пустое место.
• 🔢 Версия SQL Server. Бэкап восстанавливается только на сервер той же или более новой версии. Перенести копию с SQL Server 2022 на 2019 через RESTORE не получится.
• 📏 Редакция Express. У SQL Server Express лимит 10 ГБ на файл данных. Если копию разворачиваете на Express, а база больше, восстановление упадёт.
• 🧩 Целостность исходной базы. Битая база даст битую копию. Проверку стоит запустить в нерабочее время: она нагружает диски.

Размер файлов и их логические имена смотрим так (имя базы buh_work здесь и дальше — пример):

USE buh_work;
SELECT name AS logical_name,
       physical_name,
       size * 8 / 1024 AS size_mb
FROM sys.database_files;

Логические имена понадобятся при восстановлении. У баз, созданных из 1С, они обычно совпадают с именем базы и именем с суффиксом _log, но надеяться на это не стоит — смотрите фактические.

Проверка целостности:

DBCC CHECKDB ('buh_work') WITH NO_INFOMSGS;

Если команда ничего не вывела, кроме «Commands completed successfully», ошибок нет. Если вывела ошибки согласованности — сначала разбирайтесь с ними, а копию делайте уже с исправленной базы.

Бэкап рабочей базы 1С командой BACKUP

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

BACKUP DATABASE buh_work
TO DISK = N'D:\Backup\buh_work_copy.bak'
WITH COPY_ONLY,
     COMPRESSION,
     CHECKSUM,
     INIT,
     STATS = 10;

Что делает каждый параметр:

Путь D:\Backup\ указывается на диске сервера SQL, а не вашего компьютера. Учётная запись службы SQL Server должна иметь право записи в эту папку.

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

RESTORE VERIFYONLY
FROM DISK = N'D:\Backup\buh_work_copy.bak'
WITH CHECKSUM;

Тот же бэкап можно сделать мышкой: в SSMS правой кнопкой по базе → Tasks → Back Up..., тип Full, на странице Media Options или Backup Options отметить Copy-only backup и выбрать сжатие. Галочку Copy-only в интерфейсе забывают чаще всего, поэтому скрипт надёжнее.

Снапшот базы данных: точка отката, а не копия

Снапшот (database snapshot) часто путают с копией. Это не одно и то же, и для отдельной тестовой базы 1С снапшот не подходит.

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

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

Создание снапшота (на каждый файл данных — своя строка; файл журнала не указывается):

CREATE DATABASE buh_work_snap
ON (NAME = N'buh_work', FILENAME = N'D:\Snap\buh_work_snap.ss')
AS SNAPSHOT OF buh_work;

Откат рабочей базы к снапшоту:

USE master;
ALTER DATABASE buh_work SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
RESTORE DATABASE buh_work FROM DATABASE_SNAPSHOT = 'buh_work_snap';
ALTER DATABASE buh_work SET MULTI_USER;

Ограничения, которые важно знать:

• снапшоты есть во всех редакциях начиная с SQL Server 2016 SP1, в более ранних версиях — только в Enterprise;
• пока снапшот существует, каждая изменённая страница копируется в его файл: на нагруженной базе это заметно замедляет запись;
• файл снапшота растёт; удаляйте его сразу после того, как операция признана удачной: DROP DATABASE buh_work_snap;.

Итог: для копии, с которой будет работать человек, нужен бэкап и восстановление. Снапшот — страховка на час-два работ в самой базе.

Восстановление копии в новую базу данных SQL

Сначала узнайте логические имена файлов внутри бэкапа:

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

В колонке LogicalName будут имена файла данных и журнала. Их подставляем в MOVE, а физические пути задаём новые — иначе SQL Server попытается записать копию поверх файлов рабочей базы и откажет.

RESTORE DATABASE buh_test
FROM DISK = N'D:\Backup\buh_work_copy.bak'
WITH MOVE N'buh_work'     TO N'E:\SQLData\buh_test.mdf',
     MOVE N'buh_work_log' TO N'E:\SQLLog\buh_test_log.ldf',
     RECOVERY,
     STATS = 10;

Имя после RESTORE DATABASE должно быть новым. Если по ошибке указать имя рабочей базы и добавить REPLACE, рабочая база будет перезаписана копией.

После восстановления переведите копию в простую модель восстановления. Тестовой базе полная модель не нужна, а журнал без регламентных бэкапов будет расти до заполнения диска:

ALTER DATABASE buh_test SET RECOVERY SIMPLE;

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

Для регулярного обновления тестовой базы оба шага удобно собрать в один .bat и запускать через sqlcmd с Windows-аутентификацией:

sqlcmd -S SQLSRV -E -Q "BACKUP DATABASE buh_work TO DISK=N'D:\Backup\buh_work_copy.bak' WITH COPY_ONLY, COMPRESSION, INIT"
sqlcmd -S SQLSRV -E -i D:\Scripts\restore_buh_test.sql

В restore_buh_test.sql положите команду RESTORE с параметром REPLACE — теперь уже осознанно, для перезаписи именно buh_test. Перед ней добавьте ALTER DATABASE buh_test SET SINGLE_USER WITH ROLLBACK IMMEDIATE;, а после — SET MULTI_USER. Сеансы тестировщиков в этот момент оборвутся, поэтому запускайте скрипт вне их рабочего времени.

Подключение копии базы к кластеру серверов 1С

База SQL сама по себе в 1С не появится. Её нужно зарегистрировать в кластере как новую информационную базу.

1. Откройте консоль администрирования серверов 1С:Предприятия.
2. Раскройте кластер, на узле Информационные базы правой кнопкой → Создать → Информационная база.
3. Заполните поля:
   • Имя — имя базы в кластере, например buh_test;
   • Защищенное соединение и Тип СУБД — MS SQL Server;
   • Сервер баз данных — имя сервера SQL (с экземпляром, если он не по умолчанию: SQLSRV\INST1);
   • База данных — имя восстановленной базы SQL, buh_test;
   • Пользователь сервера БД и пароль — логин SQL, под которым 1С ходит в базу;
   • Установить блокировку регламентных заданий — включить.
4. Галочку Создать базу данных в случае ее отсутствия снимите. База уже есть, и если в имени опечатка, лучше получить ошибку, чем пустую новую базу.
5. Добавьте базу в список запуска на клиенте: Добавить → Добавление в список существующей информационной базы, тип расположения — на сервере 1С:Предприятия, имя кластера и имя базы в кластере.

Те же поля есть в окне создания базы из стартового окна 1С (Добавить → Создание новой информационной базы → Создание информационной базы без конфигурации, затем вариант «На сервере 1С:Предприятия»). Галочку создания базы данных там тоже снимите.

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

Копия содержит все настройки рабочей базы: обмены с другими базами, загрузку банковских выписок, отправку писем, обмен с ЭДО и отчётность. Без блокировки копия начнёт выполнять эти задания от имени вашей организации: заберёт сообщения обмена, отправит письма клиентам, примет входящие документы ЭДО. Рабочая база эти данные уже не получит.

Конфигурации на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) при первом входе в копию обычно сами замечают смену расположения базы и показывают предупреждение о блокировке работы с внешними ресурсами. Для тестовой копии оставьте работу с внешними ресурсами заблокированной. Разблокировать её стоит только если копия становится рабочей базой, например после переезда сервера.

Права на копию и ошибки при восстановлении

Если 1С подключается к SQL под логином с ролью sysadmin (часто sa), права на новую базу у неё уже есть. Если под отдельным логином с ограниченными правами — дайте ему доступ к копии:

USE buh_test;
CREATE USER [usr1c] FOR LOGIN [usr1c];
ALTER ROLE db_owner ADD MEMBER [usr1c];

Если копию восстанавливали на другом сервере, внутри базы уже может быть пользователь usr1c, но он не связан с логином нового сервера (так называемый «осиротевший» пользователь). Создавать его заново не нужно — достаточно связать:

USE buh_test;
ALTER USER [usr1c] WITH LOGIN = [usr1c];

Типичные сообщения и что с ними делать:

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