Как развернуть базу 1С из SQL-бэкапа

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

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

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

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

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

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

Также потребуются: права администратора на SQL Server (роль sysadmin или dbcreator), доступ к консоли кластера серверов 1С и достаточно свободного места на дисках — данных и журнала транзакций. Развёрнутая база обычно занимает в 2–4 раза больше места, чем сжатый бэкап.

Восстановление базы в SQL Server

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

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

Тот же результат даёт T-SQL команда, которая удобнее для автоматизации и повторяемых операций:

RESTORE DATABASE [MyBase1C] FROM DISK = N'D:\Backups\mybase.bak' WITH FILE = 1, MOVE N'MyBase_Data' TO N'D:\SQLData\MyBase1C.mdf', MOVE N'MyBase_Log' TO N'D:\SQLData\MyBase1C.ldf', NOUNLOAD, STATS = 10;

Логические имена файлов для параметра MOVE возьмите из вывода команды RESTORE FILELISTONLY — они не всегда совпадают с именем базы. Дождитесь сообщения об успешном завершении: база должна перейти в состояние ONLINE (а не Restoring или Suspect).

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

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

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

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

1. 1
   Скопируйте .bak на диск сервера SQL
2. 2
   Восстановите базу через SSMS или RESTORE DATABASE
3. 3
   Проверьте, что база в состоянии ONLINE
4. 4
   Откройте консоль кластера 1С, создайте информационную базу
5. 5
   Укажите имя восстановленной БД, не создавая новую
6. 6
   Запустите конфигуратор и проверьте версию конфигурации
7. 7
   Выполните тестовый вход в режиме предприятия

Проверка результата после развёртывания

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

Войдите в режим предприятия под тестовым пользователем и проверьте содержимое: список документов за последние даты до момента бэкапа, остатки по складу или взаиморасчёты, справочники контрагентов и номенклатуры. Данные должны соответствовать дате снятия копии — ничего новее в базе быть не может.

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

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

Самая частая проблема — «Ошибка СУБД: база данных не найдена» при запуске 1С. Причина почти всегда в рассинхронизации имени базы в консоли кластера и реального имени в SQL Server, либо в отсутствии у пользователя СУБД прав на базу. Проверьте сопоставление логина SQL и пользователя базы: после восстановления на другом сервере связь логин–пользователь часто разрывается (проблема «orphaned users»), её решает команда ALTER USER ... WITH LOGIN.

Вторая типичная ситуация — база зависла в состоянии Restoring. Это значит, что восстановление выполнялось с опцией NORECOVERY и не было завершено. Лечится командой RESTORE DATABASE [имя] WITH RECOVERY.

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

Особенности для PostgreSQL и файлового варианта

Если 1С работает на PostgreSQL, бэкап обычно снят через pg_dump или pg_basebackup. Восстановление выполняется командами createdb и psql (или pg_restore для custom-формата), после чего база так же регистрируется в консоли кластера с типом СУБД PostgreSQL. Важно, чтобы расширение для 1С и версия PostgreSQL соответствовали требованиям платформы.

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

Когда восстановление лучше доверить специалисту

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

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

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