Как развернуть бэкап 1С из файла .bak

Файл с расширением .bak — это резервная копия базы данных Microsoft SQL Server, в которой работает клиент-серверная 1С. Развернуть такой бэкап напрямую через конфигуратор нельзя: сначала копию нужно восстановить средствами SQL Server, а уже потом зарегистрировать базу в консоли кластера 1С или в списке информационных баз.

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

Ниже разобран полный цикл: от проверки исходного файла до подключения базы к 1С и контроля результата. Инструкции подходят для связки 1С:Предприятие 8.3 и Microsoft SQL Server со стандартной схемой развёртывания.

Что такое файл .bak и чем он отличается от выгрузки .dt

В экосистеме 1С существуют два принципиально разных формата резервных копий. Файл .dt создаётся через конфигуратор (Администрирование → Выгрузить информационную базу) и содержит данные в универсальном формате платформы — его можно загрузить и в файловый, и в клиент-серверный вариант. Файл .bak — это нативная копия SQL Server, созданная командой BACKUP DATABASE или планом обслуживания.

Ключевое отличие — привязка к СУБД. Бэкап .bak можно восстановить только на SQL Server, причём версия целевого сервера должна быть не ниже версии, на которой копия создавалась. Обратная миграция (с новой версии на старую) невозможна штатными средствами. Зато восстановление из .bak происходит значительно быстрее загрузки .dt и сохраняет базу «как есть» на момент копирования.

Что проверить перед восстановлением

Прежде чем запускать восстановление, убедитесь, что у вас есть всё необходимое. Потребуется: доступ к серверу СУБД с правами sysadmin или dbcreator, достаточный объём свободного места на дисках под файлы данных и журнал транзакций, а также сам файл .bak, доступный с сервера SQL (учётная запись службы SQL Server должна иметь к нему доступ на чтение).

Полезно заранее выяснить, из какой среды взята копия. Если бэкап сделан на SQL Server 2019, а у вас развёрнут SQL Server 2016, восстановление завершится ошибкой несовместимости версий. Версию исходного сервера можно узнать, прочитав заголовок файла командой RESTORE HEADERONLY.

RESTORE HEADERONLY FROM DISK = N'D:\Backups\base1c.bak';

В выводе этой команды смотрите поля SoftwareVersionMajor/SoftwareVersionMinor (версия SQL Server), DatabaseName (исходное имя базы) и DatabaseBackupSize (примерный размер данных). Это поможет спланировать размещение файлов и убедиться, что бэкап вообще читается.

Восстановление .bak через SQL Server Management Studio

Самый наглядный способ — графический интерфейс SQL Server Management Studio (SSMS). Подключитесь к серверу СУБД, откройте контекстное меню узла «Базы данных» и выберите «Восстановить базу данных». В качестве источника укажите «Устройство» и добавьте файл .bak.

В поле «Назначение» задайте имя новой базы — для тестовой копии используйте отличное от рабочей имя, например base1c_test. На вкладке «Файлы» проверьте пути размещения файлов данных (.mdf) и журнала (.ldf): по умолчанию SSMS предложит каталоги исходного сервера, которых может не существовать на вашем. На вкладке «Параметры» для восстановления поверх существующей базы отметьте «Перезаписать существующую базу данных (WITH REPLACE)» — для новой базы эта опция не нужна.

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

Восстановление через T-SQL

Для автоматизации или работы без графического интерфейса используется команда RESTORE DATABASE. Сначала полезно посмотреть логические имена файлов внутри бэкапа — они понадобятся для перенаправления файлов в нужные каталоги.

RESTORE FILELISTONLY FROM DISK = N'D:\Backups\base1c.bak';

Затем выполните само восстановление, указав новые пути через конструкцию MOVE. Это обязательно, если на целевом сервере другая структура дисков или если рядом уже существует база с теми же физическими файлами.

RESTORE DATABASE [base1c_test] FROM DISK = N'D:\Backups\base1c.bak' WITH MOVE N'base1c_Data' TO N'D:\SQLData\base1c_test.mdf', MOVE N'base1c_Log' TO N'D:\SQLData\base1c_test.ldf', REPLACE, STATS = 10;

Логические имена (первый аргумент MOVE) возьмите из вывода FILELISTONLY — в базах 1С они часто отличаются от показанных в примере. Параметр STATS = 10 выводит прогресс восстановления каждые 10 процентов, что удобно для больших баз.

Регистрация восстановленной базы в сервере 1С

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

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

Если сервер 1С и SQL Server работают на разных машинах, учётная запись агента сервера 1С (обычно USR1CV8) должна иметь права на базу в SQL Server. Проще всего при создании ИБ указать SQL-аутентификацию с существующим логином, либо заранее выдать учётной записи агента роль db_owner на восстановленную базу.

Что сделать после восстановления копии

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

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

Проверка результата и контрольные точки

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

Если база восстанавливалась после сбоя и будет использоваться как рабочая, рекомендуется выполнить проверку целостности средствами SQL Server (DBCC CHECKDB) и тестирование и исправление в конфигураторе 1С. Это займёт время, но позволит выявить повреждения до того, как с базой начнут работать пользователи.

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