Как восстановить копию базы 1С из SQL-бэкапа

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

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

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

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

Сначала убедитесь, что у вас есть сам файл бэкапа (.bak) и он читаемый. Если бэкап хранится в архиве или на сетевом ресурсе, скопируйте его локально на диск SQL-сервера — восстановление по сети медленнее и чаще обрывается из-за прав доступа. Учётная запись службы SQL Server должна иметь право чтения файла.

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

Уточните, что именно вы восстанавливаете: рабочую базу поверх текущей или копию для анализа. Для копии выберите новое имя базы данных, чтобы не затереть рабочие данные. Также оцените свободное место на диске: восстановленная база займёт примерно столько же, сколько занимала исходная, плюс место под журнал транзакций.

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

Самый наглядный способ — графический интерфейс SSMS. Подключитесь к нужному экземпляру SQL Server под учётной записью с правами администратора (sysadmin). В обозревателе объектов щёлкните правой кнопкой по узлу «Базы данных» и выберите «Восстановить базу данных».

В окне восстановления укажите источник «Устройство», добавьте файл .bak, задайте имя целевой базы. Если восстанавливаете копию рядом с существующей базой, обязательно перейдите на вкладку «Файлы» и измените пути физических файлов данных и журнала — иначе SSMS попытается записать данные поверх файлов рабочей базы.

На вкладке «Параметры» при восстановлении поверх существующей базы включите флажок «Перезаписать существующую базу данных (WITH REPLACE)». Для новой копии этот флажок не нужен. После нажатия «ОК» дождитесь завершения процесса и сообщения об успешном восстановлении.

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

Восстановление через T-SQL: команда RESTORE DATABASE

Опытные администраторы предпочитают скрипты: их можно сохранить, повторить и автоматизировать. Сначала полезно посмотреть, какие логические файлы содержатся в бэкапе, командой RESTORE FILELISTONLY — это нужно, чтобы правильно указать новые пути при восстановлении копии.

Основная команда выглядит так: укажите имя целевой базы, путь к файлу бэкапа и, при необходимости, предложения MOVE для переноса файлов данных и журнала в новое расположение. Без MOVE при восстановлении копии SQL Server попытается использовать пути, записанные в бэкапе, что приведёт к конфликту с рабочей базой.

RESTORE FILELISTONLY FROM DISK = 'D:\Backup\base_copy.bak';
GO
RESTORE DATABASE [Base1C_Copy]
FROM DISK = 'D:\Backup\base_copy.bak'
WITH MOVE 'Base1C' TO 'D:\SQLData\Base1C_Copy.mdf',
     MOVE 'Base1C_log' TO 'D:\SQLData\Base1C_Copy.ldf',
     RECOVERY, STATS = 10;

Параметр RECOVERY переводит базу в рабочее состояние сразу после восстановления — именно он нужен в большинстве случаев. Вариант NORECOVERY применяется только при последовательном накате нескольких бэкапов (полного и разностных или журналов). Прогресс выполнения показывает параметр STATS.

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

SQL-бэкап не содержит регистрации в кластере 1С, поэтому после восстановления базу нужно «привязать» к серверу 1С. Откройте консоль администрирования серверов 1С, разверните нужный кластер, щёлкните правой кнопкой по ветке «Информационные базы» и выберите «Создать» → «Информационная база».

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

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

Проверка результата и целостности данных

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

Для глубокой проверки запустите конфигуратор и выполните «Тестирование и исправление» в режиме проверки логической целостности без исправления — сначала только диагностику. На стороне СУБД полезно выполнить команду DBCC CHECKDB, чтобы убедиться в отсутствии физических повреждений восстановленной базы.

Типичные ошибки и их решение

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

Вторая типичная ситуация — ошибка «база данных используется» при восстановлении поверх существующей. Завершите сеансы пользователей в консоли кластера 1С, остановите фоновые задания и при необходимости переведите базу в однопользовательский режим командой ALTER DATABASE с параметром SINGLE_USER WITH ROLLBACK IMMEDIATE, не забыв вернуть MULTI_USER после.

Третья группа ошибок связана с пользователями SQL Server. После восстановления базы на другой сервер логины сервера и пользователи базы «разрываются»: пользователь базы есть, а соответствующего логина на сервере нет. Создайте логин с тем же именем и свяжите его с пользователем базы, либо назначьте базе существующий логин с нужными правами.

Особые сценарии: разностные бэкапы и переезд на другой сервер

Восстановление цепочки: полный + разностный бэкап

Если бэкапы снимались по схеме «полный + разностные», сначала восстановите полный бэкап с параметром NORECOVERY, затем последний разностный — уже с RECOVERY. Промежуточные разностные копии не нужны: каждая содержит все изменения с момента полного бэкапа.

Перенос базы на другой сервер

При переезде на новый сервер дополнительно проверьте: версию и разрядность SQL Server, настройки сортировки (Collation) экземпляра — для 1С обычно требуется Cyrillic_General_CI_AS, наличие нужных логинов и достаточное дисковое пространство. Несовпадение collation экземпляра — редкая, но трудно исправимая проблема, её проще предотвратить до установки SQL Server.

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