Восстанавливаем базу 1С из .bak в MS SQL Server и подключаем её к серверу 1С
Содержание
Чтобы развернуть базу 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. Названия ниже даны по английскому интерфейсу, в русском они переведены дословно.
- Подключитесь к экземпляру SQL Server в Object Explorer.
- Щёлкните правой кнопкой по узлу
Databasesи выберитеRestore Database…. - На странице
Generalв блокеSourceвыберитеDeviceи нажмите кнопку…. - В окне выбора носителя нажмите
Addи укажите файл.bak. - В таблице
Backup sets to restoreотметьте нужный набор. Если там несколько строк, ориентируйтесь на дату и тип (Full,Differential,Transaction Log). - В блоке
Destinationв полеDatabaseвпишите имя новой базы, напримерbuh_copy. - Перейдите на страницы
FilesиOptions— их настройки разобраны в следующих разделах. - Нажмите
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 | нужно заглядывать в базу между накатами журналов | база доступна только на чтение |
Цепочка: полный + разностный + журналы
Если нужен срез на конкретный час, порядок такой:
- Полный бэкап —
WITH NORECOVERY. - Последний разностный после него —
WITH NORECOVERY. - Журналы транзакций по порядку —
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, этот шаг не нужен.