Восстанавливаем базу 1С из .bak в MS SQL Server и подключаем её к серверу 1С

· 10 мин

Содержание

Чтобы развернуть базу 1С из SQL-бэкапа, восстановите файл .bak в SQL Server Management Studio (правый клик по Databases → Restore Database…), задайте новое имя базы и пути файлов, а затем зарегистрируйте эту базу данных в кластере серверов 1С и добавьте её в список информационных баз. Сам SQL-бэкап ничего не знает о сервере 1С: без регистрации в кластере база останется просто набором таблиц.

Порядок действий одинаков для клиент-серверной 1С 8.3 на Microsoft SQL Server. Он подходит и для переноса базы на другой сервер, и для создания тестовой копии рядом с рабочей. Для PostgreSQL файл .bak не годится: там свои инструменты (pg_dump, pg_restore).

Что проверить до восстановления SQL-бэкапа

Ошибку в версии сервера или нехватку места лучше поймать до запуска мастера, а не через час восстановления 200-гигабайтной базы.

Версия SQL Server

Бэкап, снятый на более новой версии SQL Server, на более старую не восстанавливается. Копия с SQL Server 2022 не поднимется на 2017 — сервер ответит ошибкой о несовместимой версии. В обратную сторону (со старой на новую) всё работает.

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

Место на дисках

Восстановленная база занимает столько же, сколько занимала исходная, вместе с файлом журнала. Размер .bak тут обманчив: бэкап сжат и не содержит пустого места в файлах.

Узнать реальные размеры можно командой (о ней ниже): колонка Size покажет объём каждого файла в байтах.

Содержимое и целостность файла

Три команды T-SQL отвечают на вопросы «что внутри» и «читается ли файл»:

-- какие бэкапы лежат в файле (их может быть несколько)
RESTORE HEADERONLY FROM DISK = N'D:\Backup\buh.bak';

-- логические имена и размеры файлов базы
RESTORE FILELISTONLY FROM DISK = N'D:\Backup\buh.bak';

-- проверка, что файл читается целиком
RESTORE VERIFYONLY FROM DISK = N'D:\Backup\buh.bak' WITH CHECKSUM;

📌 HEADERONLY важен, если в один файл дописывали бэкапы несколько дней подряд. Колонка Position покажет номер каждого набора, а BackupFinishDate — когда он снят.

📌 VERIFYONLY не гарантирует, что внутри нет повреждённых страниц. Он проверяет читаемость носителя и контрольные суммы, если бэкап снимали с CHECKSUM. Полную проверку даст только DBCC CHECKDB после восстановления.

Доступ службы SQL Server к файлу

Файл читает не ваша учётная запись, а служба SQL Server. Если .bak лежит на сетевой папке или в профиле пользователя, у службы может не оказаться прав. Проще всего скопировать бэкап на локальный диск сервера, например в стандартную папку Backup экземпляра.

Восстановление базы 1С из SQL-бэкапа в Management Studio

Мастер одинаков во всех актуальных версиях SSMS. Названия ниже даны по английскому интерфейсу, в русском они переведены дословно.

  1. Подключитесь к экземпляру SQL Server в Object Explorer.
  2. Щёлкните правой кнопкой по узлу Databases и выберите Restore Database….
  3. На странице General в блоке Source выберите Device и нажмите кнопку ….
  4. В окне выбора носителя нажмите Add и укажите файл .bak.
  5. В таблице Backup sets to restore отметьте нужный набор. Если там несколько строк, ориентируйтесь на дату и тип (Full, Differential, Transaction Log).
  6. В блоке Destination в поле Database впишите имя новой базы, например buh_copy.
  7. Перейдите на страницы Files и Options — их настройки разобраны в следующих разделах.
  8. Нажмите OK и дождитесь сообщения об успешном восстановлении.

Мастер по умолчанию подставляет в Destination имя исходной базы. Если на сервере уже есть база с таким именем, вы рискуете затереть рабочие данные. Всегда проверяйте поле Database перед нажатием OK.

💡 Восстанавливая копию для тестов или проверки отчётов, давайте ей говорящее имя: buh_test_0710, zup_copy. Через полгода никто не вспомнит, что такое buh2.

Куда положить файлы базы данных

Страница Files решает, где окажутся файлы данных (.mdf) и журнала (.ldf). Мастер подставляет пути исходного сервера. Если на новом сервере таких папок нет или там лежат файлы рабочей базы, восстановление упадёт или, хуже, попытается их перезаписать.

Варианты на этой странице:

  • 📁 Relocate all files to folder — перенести все файлы в две папки: отдельно данные, отдельно журнал. Самый быстрый способ.
  • ✏️ Restore As в таблице — задать путь и имя каждому файлу вручную.

Для копии рабочей базы меняйте и имена файлов, а не только папки. Иначе buh.mdf новой базы может попытаться лечь на место buh.mdf рабочей.

ФайлТипичное размещениеПочему так
Данные .mdfотдельный быстрый диск, например E:\SQLDataосновная нагрузка при работе 1С
Журнал .ldfдругой диск, например F:\SQLLogпоследовательная запись, не мешает чтению данных
Бэкапы .bakтретий диск или сетевое хранилищебэкап не должен погибнуть вместе с диском базы

Для тестовой копии всё можно сложить на один диск — скорость там не критична.

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

Страница Options отвечает за поведение при конфликте с существующей базой и за состояние базы после восстановления.

Блок Restore options

  • 🔁 Overwrite the existing database (WITH REPLACE) — нужен, когда вы сознательно восстанавливаете поверх существующей базы. Без этого флага SQL Server откажет, если бэкап принадлежит другой базе.
  • 🔒 Restrict access to the restored database (WITH RESTRICTED_USER) — после восстановления к базе смогут подключиться только администраторы. Удобно, если базу нужно сначала проверить.

Tail-log и активные подключения

Флаг Take tail-log backup before restore снимает «хвост» журнала с базы, которую вы перезаписываете. При восстановлении в базу с новым именем его нужно снять. Иначе мастер может снять хвостовой бэкап с исходной базы на этом же сервере и оставить её в состоянии Restoring.

Флаг Close existing connections to destination database разрывает все подключения к базе-приёмнику.

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

Recovery state

РежимКогда выбиратьЧто будет с базой
RESTORE WITH RECOVERYвосстанавливаете один полный бэкап или последний файл цепочкибаза сразу доступна
RESTORE WITH NORECOVERYпосле полного бэкапа будете накатывать разностный и журналыбаза в состоянии Restoring, ждёт следующий файл
RESTORE WITH STANDBYнужно заглядывать в базу между накатами журналовбаза доступна только на чтение

Цепочка: полный + разностный + журналы

Если нужен срез на конкретный час, порядок такой:

  1. Полный бэкап — WITH NORECOVERY.
  2. Последний разностный после него — WITH NORECOVERY.
  3. Журналы транзакций по порядку — WITH NORECOVERY, последний — WITH RECOVERY.

Для точки во времени у последнего журнала укажите STOPAT = '2026-10-06T14:30:00'. В мастере это кнопка Timeline на странице General.

То же самое скриптом T-SQL

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

Сначала узнайте логические имена файлов через RESTORE FILELISTONLY (колонка LogicalName). Допустим, это buh и buh_log:

RESTORE DATABASE [buh_copy]
FROM DISK = N'D:\Backup\buh.bak'
WITH FILE = 1,
     MOVE N'buh'     TO N'E:\SQLData\buh_copy.mdf',
     MOVE N'buh_log' TO N'F:\SQLLog\buh_copy_log.ldf',
     RECOVERY,
     STATS = 10;
  • FILE = 1 — номер набора из колонки Position в HEADERONLY.
  • MOVE — куда положить каждый логический файл.
  • STATS = 10 — сообщение о прогрессе каждые 10%.

Восстановление поверх существующей базы с принудительным отключением сеансов:

ALTER DATABASE [buh_test] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

RESTORE DATABASE [buh_test]
FROM DISK = N'D:\Backup\buh.bak'
WITH REPLACE,
     MOVE N'buh'     TO N'E:\SQLData\buh_test.mdf',
     MOVE N'buh_log' TO N'F:\SQLLog\buh_test_log.ldf',
     RECOVERY;

ALTER DATABASE [buh_test] SET MULTI_USER;

💡 Для тестовой копии сразу переключите модель восстановления на простую: ALTER DATABASE [buh_copy] SET RECOVERY SIMPLE;. Иначе журнал копии будет расти без ограничений, ведь бэкапы журнала для неё никто не настраивал.

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

Сервер 1С работает с базой данных через собственную регистрацию в кластере. Без неё база из бэкапа в списке не появится.

Регистрация в кластере

Есть два равноценных пути.

Через консоль администрирования серверов 1С. Откройте кластер, правой кнопкой по узлу Информационные базы → Создать → Информационная база. Заполните:

  • Имя — как база будет называться в кластере, например buh_copy;
  • Сервер баз данных — имя экземпляра SQL Server (sqlsrv или sqlsrv\INST);
  • Тип СУБД — MS SQL Server;
  • База данных — точное имя восстановленной базы в SQL;
  • Пользователь сервера БД и пароль — логин SQL, под которым 1С ходит в СУБД;
  • Смещение дат — такое же, как у исходной базы. Для MS SQL обычно 2000;
  • флаг Создать базу данных в случае ее отсутствия — снимите: база уже есть.

Через окно запуска 1С. Добавить → Создание новой информационной базы → Создание информационной базы без конфигурации → тип расположения На сервере 1С:Предприятия. Поля те же, что выше. Если база данных с таким именем уже существует и содержит данные 1С, платформа не создаёт её заново, а подключается к ней.

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

Не регистрируйте две информационные базы кластера на одну и ту же базу данных SQL. Это прямой путь к порче данных.

Добавление в список у пользователей

Если база уже зарегистрирована в кластере (например, через консоль), на рабочих местах выберите Добавить → Добавление в список существующей информационной базы → На сервере 1С:Предприятия. Укажите имя сервера 1С (при нестандартном порте — srv1c:2541) и имя базы в кластере.

Первый запуск копии

Типовые конфигурации на БСП при запуске замечают, что строка подключения изменилась. Программа спросит, перемещена ли база или это её копия. Для тестовой базы отвечайте, что это копия: тогда работа с внешними ресурсами (обмены, почта, интернет-сервисы) останется заблокированной.

Права SQL-пользователя и ошибки при развертывании

После переноса на другой сервер чаще всего ломаются права. Пользователи базы SQL хранятся внутри бэкапа и привязаны к логинам исходного сервера по SID. На новом сервере логин с тем же именем имеет другой SID, и пользователь базы становится «сиротой».

Как найти и починить «осиротевших» пользователей

USE [buh_copy];

SELECT dp.name
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON dp.sid = sp.sid
WHERE dp.type = 'S'
  AND dp.principal_id > 4
  AND sp.sid IS NULL;

Каждого найденного пользователя привяжите к логину сервера:

ALTER USER [onec] WITH LOGIN = [onec];

Логину, под которым работает сервер 1С, нужна роль db_owner в восстановленной базе. Если 1С подключается под sa или другим логином с ролью sysadmin, этот шаг не нужен.

Диагностика: выберите симптом

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

Можно ли из SQL-бэкапа сразу получить файловую базу 1С?
Нет. Сначала восстановите .bak на SQL Server и зарегистрируйте базу в кластере, затем выгрузите .dt через Конфигуратор и загрузите его в новую файловую базу.
Нужно ли заново создавать пользователей 1С после восстановления?
Нет. Список пользователей 1С с паролями хранится внутри базы и восстанавливается вместе с ней. Заново настраиваются только права SQL-логинов на уровне сервера СУБД.
Нужны ли отдельные лицензии на тестовую копию базы?
Клиентские лицензии расходуются на сеансы пользователей, а не на число баз. Копия на том же сервере 1С работает в рамках имеющихся лицензий, но её сеансы тоже их занимают.
Сколько длится восстановление?
Зависит от размера базы и скорости дисков. Ориентир на SSD — несколько минут на 50–100 ГБ. Прогресс видно в мастере или по сообщениям STATS в скрипте.
Чем SQL-бэкап лучше выгрузки .dt?
Бэкап снимается без остановки работы пользователей и восстанавливается быстрее. Выгрузка .dt нужна для переноса между разными СУБД, версиями SQL Server или в файловый вариант.