Разворачиваем резервную копию MS SQL в рабочую базу 1С

Файл .bak восстанавливают средствами Microsoft SQL Server, а не самой 1С: в SQL Server Management Studio (SSMS) или командой RESTORE DATABASE. После этого базу данных SQL регистрируют в кластере серверов 1С, и она открывается как обычная информационная база.

Чтобы восстановить базу 1С из резервной копии без сюрпризов, проверьте три вещи заранее: версию SQL Server, на которой сделан бэкап, место на диске и права службы SQL на папку с файлом. Если у вас файл .dt, это выгрузка самой 1С, её загружают через Конфигуратор, и описанное ниже к ней не относится.

Подготовка: что проверить до восстановления из .bak

Начните с того, что внутри архива. Три команды в SSMS (New Query, база master) отвечают на все вопросы до начала восстановления.

Читается ли архив целиком

RESTORE VERIFYONLY
FROM DISK = N'D:\Backup\buh_full.bak';

Ответ The backup set on file 1 is valid значит, что файл не обрезан и читается. Если бэкап делали с параметром CHECKSUM, команда заодно сверит контрольные суммы страниц.

Какая версия SQL Server сделала копию

RESTORE HEADERONLY
FROM DISK = N'D:\Backup\buh_full.bak';

Смотрите колонки:

• 🔢 SoftwareVersionMajor — версия сервера-источника;
• 📅 BackupFinishDate — когда закончилось копирование;
• 🗂 BackupType — 1 полная, 5 разностная, 2 журнал транзакций;
• 📦 Position — номер набора, если в одном файле лежит несколько копий.

Бэкап восстанавливается только на сервер той же или более новой версии. Обратно — никак.

Свою версию узнайте запросом SELECT @@VERSION;.

Сколько места понадобится

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

Команда покажет логические имена файлов (LogicalName), исходные пути (PhysicalName), тип (D — данные, L — журнал) и размер в байтах (Size).

Считайте место по колонке Size, а не по размеру .bak. Сжатый бэкап на 15 ГБ легко разворачивается в базу на 60 ГБ плюс журнал на 20 ГБ, потому что журнал создаётся с тем размером, который был у источника.

Видит ли SQL Server сам файл

Файл читает служба SQL Server, а не ваша учётная запись. Отсюда два правила:

1. Учётной записи службы (по умолчанию NT Service\MSSQLSERVER) нужны права на чтение папки с .bak и на запись в папки, куда лягут .mdf и .ldf.
2. Сетевой диск указывайте UNC-путём (\\nas\backup\buh_full.bak). Подключённые буквы вроде Z: служба не видит.

Надёжнее всего скопировать .bak на локальный диск сервера СУБД.

Восстановление базы 1С из .bak через SSMS

Графический мастер подходит, когда нужна одна полная копия или короткая цепочка. Сценарий ниже — новая база-копия рядом с рабочей, например для проверки или тестов.

Шаг 1. Источник

1. В Object Explorer щёлкните правой кнопкой по папке Databases и выберите Restore Database....
2. На странице General переключите источник на Device, нажмите ..., затем Add и выберите файл.
3. В поле Database впишите имя новой базы, например buh_copy. Имя должно отличаться от рабочей базы, иначе мастер начнёт перезаписывать её.
4. В таблице Backup sets to restore отметьте нужные наборы. Если в файле есть полная и разностная копии, мастер сам выстроит цепочку.

Шаг 2. Файлы

На странице Files включите Relocate all files to folder и задайте папки для данных и журнала. Иначе SQL попытается положить файлы по исходным путям — туда, где лежат файлы рабочей базы, и упадёт с ошибкой «файл используется».

Проверьте колонку Restore As: в именах файлов должно стоять новое имя базы.

Шаг 3. Параметры

На странице Options:

• Overwrite the existing database (WITH REPLACE) — только если сознательно заменяете существующую базу;
• Recovery state — RESTORE WITH RECOVERY, если после этой копии больше ничего накатывать не будете;
• Take tail-log backup before restore — снимите, когда восстанавливаете в новую базу;
• Close existing connections to destination database — нужен, только если перезаписываете базу, в которой сидят пользователи.

Нажмите OK. Прогресс виден внизу окна, на большой базе это десятки минут.

Восстановление из файла .bak командами T-SQL

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

Одна полная копия в новую базу

Логические имена из FILELISTONLY подставьте в MOVE:

USE master;
RESTORE DATABASE [buh_copy]
FROM DISK = N'D:\Backup\buh_full.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. STATS = 10 печатает прогресс каждые 10%.

Замена существующей базы

Если нужно вернуть рабочую базу к состоянию из бэкапа, сначала выгоните из неё соединения:

USE master;
ALTER DATABASE [buh] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

RESTORE DATABASE [buh]
FROM DISK = N'D:\Backup\buh_full.bak'
WITH REPLACE, RECOVERY, STATS = 10;

ALTER DATABASE [buh] SET MULTI_USER;

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

Когда нужно состояние на конкретную минуту, восстанавливают по порядку: полную копию, последнюю разностную после неё и все журналы транзакций после разностной. Все шаги, кроме последнего, идут с NORECOVERY:

USE master;
RESTORE DATABASE [buh_copy] FROM DISK = N'D:\Backup\buh_full.bak'
WITH NORECOVERY, REPLACE,
     MOVE N'buh'     TO N'E:\SQLData\buh_copy.mdf',
     MOVE N'buh_log' TO N'F:\SQLLog\buh_copy_log.ldf';

RESTORE DATABASE [buh_copy] FROM DISK = N'D:\Backup\buh_diff.bak'
WITH NORECOVERY;

RESTORE LOG [buh_copy] FROM DISK = N'D:\Backup\buh_log_1300.trn'
WITH NORECOVERY;

RESTORE LOG [buh_copy] FROM DISK = N'D:\Backup\buh_log_1400.trn'
WITH STOPAT = N'2025-03-14T13:47:00', RECOVERY;

STOPAT останавливает накат на указанном моменте. Удобно, когда кто-то в 13:48 массово перепровёл документы или удалил справочник.

Если по ошибке закончили шаг с RECOVERY, дальше журналы не накатятся: цепочку придётся начинать с полной копии заново. А база, оставшаяся в состоянии Restoring..., доводится до рабочего вида одной командой RESTORE DATABASE [buh_copy] WITH RECOVERY;.

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

Пока пользователи не зашли, потратьте 10-20 минут на проверку.

Целостность

DBCC CHECKDB (N'buh_copy') WITH NO_INFOMSGS;

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

Модель восстановления и журнал

Копия для тестов наследует модель FULL от рабочей базы. Без заданий резервного копирования журнала её .ldf будет расти бесконечно. Переведите копию в простую модель и ужмите журнал:

ALTER DATABASE [buh_copy] SET RECOVERY SIMPLE;
USE [buh_copy];
DBCC SHRINKFILE (N'buh_log', 1024);

Логическое имя журнала после восстановления остаётся прежним (buh_log), даже если физический файл называется иначе.

Пользователь, под которым ходит 1С

Если кластер подключается к SQL не под sa, а под отдельным логином, на новом сервере этот пользователь базы окажется «осиротевшим»: он есть внутри базы, но не связан с логином сервера. Свяжите их:

USE [buh_copy];
ALTER USER [user1c] WITH LOGIN = [user1c];

Логин user1c должен заранее существовать на сервере. Заодно проверьте владельца базы: ALTER AUTHORIZATION ON DATABASE::[buh_copy] TO [sa];.

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

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

Создание информационной базы в консоли

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

Смещение дат: 0 или 2000

Это частая ловушка. Базы на MS SQL, созданные через 1С, обычно имеют смещение 2000. Посмотрите значение в свойствах исходной базы в консоли и поставьте такое же. При неверном смещении даты в документах уедут на 2000 лет, и база выглядит «сломанной», хотя данные целы.

Почему копию нужно изолировать

Восстановленная копия с работающими регламентными заданиями сама начнёт делать то, что делала рабочая база: загружать банковские выписки, отправлять почту, обмениваться с другими базами и с ЭДО. Вторые выгрузки из копии портят данные в настоящих базах-получателях.

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

Подключение у пользователя

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

Srvr="srv1c";Ref="buh_copy";

После входа загляните в последние документы журнала: дата и время самого свежего должны совпадать с BackupFinishDate из HEADERONLY или с моментом STOPAT.

Ошибки SQL Server при восстановлении базы и что делать

Сообщения ниже — то, что SQL Server выдаёт чаще всего. Номер ошибки стоит в начале текста (Msg 3154).

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

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