Как развернуть .bak в SQL Server и снова запустить базу 1С на сервере

Чтобы восстановить базу 1С из SQL бэкапа, разверните файл .bak средствами SQL Server (мастер Restore Database в SSMS или команда RESTORE DATABASE), а затем зарегистрируйте полученную базу данных в кластере серверов 1С через консоль администрирования. Сама платформа 1С файл .bak не читает: это работа на стороне СУБД.

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

Подготовка: версия SQL Server, место на диске и проверка бэкапа

До запуска восстановления проверьте три вещи. Каждая из них потом превращается в ошибку, если её пропустить.

Версия SQL Server

Бэкап разворачивается только на той же или более новой версии SQL Server. Файл, снятый на SQL Server 2022, на 2019 не восстановится ни при каких настройках. Версию сервера покажет запрос:

SELECT @@VERSION;

Версию сервера, где делали бэкап, видно в заголовке файла:

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

Смотрите колонки DatabaseName, BackupFinishDate и SoftwareVersionMajor. Заодно убедитесь, что в файле нужная дата: в один .bak бывает дописано несколько наборов, и тогда нужный выбирают параметром FILE = N.

Место и путь к файлу

• 📁 Положите .bak на локальный диск сервера СУБД. Служба SQL Server читает файл от имени своей учётной записи, и сетевой диск, подключённый у вас в сеансе, она не увидит.
• 💾 Свободного места нужно не меньше, чем занимали файлы данных и журнала у исходной базы, а не размер .bak. Сжатый бэкап на 20 ГБ легко разворачивается в базу на 60–80 ГБ.
• 🔍 Логические имена файлов и их исходный размер покажет команда:

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

Колонки LogicalName и PhysicalName понадобятся на следующем шаге.

Целостность бэкапа

Быстрая проверка без восстановления:

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

Как восстановить базу 1С из SQL бэкапа в SSMS и через T-SQL

Через мастер SQL Server Management Studio

1. В Object Explorer щёлкните правой кнопкой по папке Databases и выберите Restore Database....
2. В блоке Source отметьте Device, нажмите ..., затем Add и укажите файл .bak.
3. В блоке Destination в поле Database введите имя новой базы, например buh_test.
4. На странице Files включите Relocate all files to folder и укажите папки для данных и журнала. Проверьте, что в колонке Restore As имена файлов новые, а не совпадают с файлами рабочей базы.
5. На странице Options оставьте Recovery state: RESTORE WITH RECOVERY.
6. Нажмите OK и дождитесь сообщения об успешном восстановлении.

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

Через T-SQL

Скрипт удобнее мастера: его можно сохранить и повторять. Логические имена (buh, buh_log) подставьте из вывода RESTORE FILELISTONLY:

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

STATS = 10 выводит прогресс каждые 10%, чтобы было видно, что процесс идёт.

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

Если база в модели Full и бэкапы идут цепочкой, порядок такой: полный бэкап → последний разностный → все журналы после него. Все шаги, кроме последнего, выполняются с NORECOVERY:

RESTORE DATABASE [buh_test] FROM DISK = N'D:\Backup\buh_full.bak'
  WITH MOVE N'buh' TO N'E:\SQLData\buh_test.mdf',
       MOVE N'buh_log' TO N'F:\SQLLog\buh_test_log.ldf', NORECOVERY;
RESTORE DATABASE [buh_test] FROM DISK = N'D:\Backup\buh_diff.bak' WITH NORECOVERY;
RESTORE LOG [buh_test] FROM DISK = N'D:\Backup\buh_log_1.trn'
  WITH STOPAT = N'2026-10-05T14:30:00', RECOVERY;

STOPAT возвращает базу на точное время, например на минуту до ошибочной групповой обработки.

Восстановление поверх рабочей базы 1С

Этот путь нужен при аварии. Всё, что пользователи внесли после момента бэкапа, пропадёт. Если сомневаетесь, сначала восстановите копию в отдельную базу и сравните данные.

Порядок действий:

1. Предупредите пользователей: их сеансы будут прерваны, несохранённые документы потеряются. Лучше делать это вне рабочего времени.
2. В консоли администрирования серверов 1С откройте свойства информационной базы, включите Блокировка начала сеансов включена и Блокировка регламентных заданий включена.
3. Завершите оставшиеся сеансы в ветке Сеансы этой базы.
4. Восстановите базу в SQL Server с перезаписью:

ALTER DATABASE [buh] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
RESTORE DATABASE [buh] FROM DISK = N'D:\Backup\buh_full.bak'
  WITH REPLACE, STATS = 10;
ALTER DATABASE [buh] SET MULTI_USER;

5. Снимите блокировку сеансов, зайдите в базу сами и проверьте последние документы.

В мастере SSMS то же самое делают флажки на странице Options: Overwrite the existing database (WITH REPLACE) и Close existing connections to destination database. Флажок Take tail-log backup before restore для этого сценария снимите, если не планируете сохранять хвост журнала.

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

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

Новую базу SQL (buh_test) кластер 1С пока не знает. Её нужно зарегистрировать.

1. Откройте консоль Администрирование серверов 1С Предприятия.
2. Раскройте Central 1C:Enterprise 8.3 servers → ваш сервер → Кластеры → нужный кластер → Информационные базы.
3. Правой кнопкой: Создать → Информационная база.
4. Заполните поля:

5. Нажмите ОК. На клиентском компьютере в окне запуска 1С выберите Добавить → Добавление в список существующей информационной базы → На сервере 1С:Предприятия и укажите кластер и имя buh_test.

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

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

Типовые конфигурации при первом запуске в новом месте сами блокируют работу с внешними ресурсами и спрашивают, переместили базу или это копия. Для теста выбирайте вариант «это копия». Не регистрируйте две базы кластера на одну и ту же базу SQL — это гарантированный конфликт.

Логины SQL и пользователи 1С после восстановления

Здесь два разных уровня прав, и путать их не стоит.

Уровень SQL Server: «осиротевший» пользователь

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

Найти таких пользователей:

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

Привязать пользователя к существующему логину:

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

Если логина нет, создайте его, затем пользователя в базе и дайте роль:

CREATE LOGIN [usr1c] WITH PASSWORD = N'СложныйПароль';
USE [buh_test];
CREATE USER [usr1c] FOR LOGIN [usr1c];
ALTER ROLE db_owner ADD MEMBER [usr1c];

Этот логин и пароль указываются в поле Пользователь сервера БД при регистрации в кластере.

Уровень 1С: пользователи и роли

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

• 👤 Пользователи с аутентификацией операционной системы на другом домене не войдут: привязка к доменной учётной записи укажет на несуществующего пользователя. Зайдите под пользователем с паролем и поправьте привязку в карточке.
• 🔐 Для тестовой копии разумно ограничить доступ: оставить вход только тем, кто проверяет данные.
• 🛠 В Конфигураторе список доступен в Администрирование → Пользователи, в пользовательском режиме типовых конфигураций — в разделе Администрирование.

Ошибки при восстановлении бэкапа и подключении 1С

Если база восстановилась, но 1С не стартует

• ⚙️ Версия платформы. Если бэкап сделан с базы, которая работала на более новой платформе, чем установлена на этом сервере 1С, база может не открыться. Номер платформы на сервере должен быть не ниже, чем на исходном.
• 🔤 Сортировка (collation). 1С работает с базами в Cyrillic_General_CI_AS. Если сервер SQL ставили с другой сортировкой, возможны ошибки сравнения строк во временных таблицах. Проверьте: SELECT SERVERPROPERTY('Collation');.
• 🧩 Повреждения внутри данных. Если DBCC CHECKDB на копии чист, а 1С ругается на структуру, запустите на копии Тестирование и исправление в Конфигураторе. Режим требует монопольного доступа к базе.

Автоматизация резервного копирования и регулярная проверка восстановления

Бэкап, который ни разу не восстанавливали, — это надежда, а не резервная копия.

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

В модели Full бэкапы журнала обязательны, например каждые 15–30 минут. Без них файл журнала растёт до заполнения диска.

Планы обслуживания и Планировщик заданий

В редакциях Standard и Enterprise расписание настраивают через Management → Maintenance Plans в SSMS: полный бэкап ночью, разностный днём, журналы часто. Планы работают через SQL Server Agent.

В SQL Server Express агента нет. Расписание собирают из скрипта и Планировщика заданий Windows. Скрипт backup_buh.sql:

BACKUP DATABASE [buh]
TO DISK = N'D:\Backup\buh_full.bak'
WITH INIT, CHECKSUM, STATS = 10;

Файл backup_buh.bat для Планировщика:

sqlcmd -S .\SQLEXPRESS -E -i "C:\Scripts\backup_buh.sql" -o "C:\Scripts\backup_buh.log"

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

Раз в неделю или хотя бы раз в месяц восстанавливайте свежий бэкап в buh_test и проверяйте его:

Храните хотя бы одну копию вне сервера СУБД: на другом сервере или во внешнем хранилище. Отказ диска или шифровальщик уничтожают бэкапы, лежащие рядом с базой.

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