Как восстановить бэкап 1С в SQL Server: пошаговое руководство

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

Важно различать два типа резервных копий. Первый — выгрузка из конфигуратора в файл с расширением .dt: он восстанавливается средствами 1С и не зависит от СУБД. Второй — нативный бэкап SQL Server с расширением .bak, который восстанавливается через SQL Server Management Studio или командой T-SQL. В этой статье рассматривается именно второй сценарий, а также моменты, где .dt может оказаться единственным рабочим вариантом.

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

Определите тип резервной копии и совместимость версий

Первый шаг — понять, что именно лежит в файле бэкапа. Нативный бэкап SQL Server обычно имеет расширение .bak и создаётся через план обслуживания, SSMS или скрипт BACKUP DATABASE. Такой файл привязан к версии SQL Server: бэкап, снятый на более новой версии, нельзя восстановить на более старой. Обратная совместимость работает — старый бэкап на новом сервере восстановится и будет автоматически обновлён.

Если у вас файл .dt — это выгрузка информационной базы из конфигуратора 1С. Его нельзя восстановить средствами SQL Server: сначала создаётся пустая база на SQL Server, потом пустая информационная база 1С, и уже в неё загружается .dt через конфигуратор (Администрирование → Загрузить информационную базу). Этот путь дольше и требовательнее к ресурсам, но работает между любыми версиями СУБД.

Узнать версию SQL Server, на которой снят бэкап, можно без восстановления — командой RESTORE HEADERONLY. Она вернёт служебную информацию, включая SoftwareVersionMajor и дату создания копии. Это избавит от бесплодных попыток восстановить несовместимый файл.

RESTORE HEADERONLY FROM DISK = N'D:\Backups\base1c.bak';

Подготовьте сервер и права доступа

На целевом сервере должно хватить места не только под сам файл бэкапа, но и под развёрнутую базу: размер данных после восстановления обычно заметно больше сжатого .bak. Проверьте свободное пространство на дисках, куда будут положены файлы данных (.mdf) и журнал транзакций (.ldf). Для баз 1С журнал может быть крупным, особенно если модель восстановления — Full.

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

Если восстановление идёт поверх существующей рабочей базы, завершите все сеансы пользователей 1С и отключите регламентные задания на сервере 1С. Открытые соединения не дадут выполнить RESTORE с опцией REPLACE. Альтернатива — перевести базу в однопользовательский режим с немедленным откатом транзакций, но делать это на продуктиве нужно осознанно.

Восстановите бэкап через SQL Server Management Studio

Графический способ подходит тем, кто редко работает с T-SQL. Откройте SSMS, подключитесь к серверу, в обозревателе объектов щёлкните правой кнопкой по узлу «Базы данных» и выберите «Восстановить базу данных». В качестве источника укажите «Устройство» и добавьте файл .bak.

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

После нажатия OK дождитесь завершения операции. Для больших баз процесс занимает от нескольких минут до часов — прогресс отображается в окне восстановления. Признак успеха — сообщение о том, что база данных восстановлена, и её появление в списке в состоянии Online.

1. 1
   Подключитесь к SQL Server и откройте «Восстановить базу данных»
2. 2
   Выберите источник «Устройство» и укажите файл .bak
3. 3
   На вкладке «Файлы» исправьте пути к .mdf и .ldf на существующие каталоги
4. 4
   При восстановлении поверх базы включите WITH REPLACE и закрытие соединений
5. 5
   Запустите восстановление и дождитесь сообщения об успехе
6. 6
   Проверьте, что база в списке имеет состояние Online

Восстановите бэкап командой T-SQL

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

RESTORE FILELISTONLY FROM DISK = N'D:\Backups\base1c.bak';
GO
RESTORE DATABASE [TradeBase]
FROM DISK = N'D:\Backups\base1c.bak'
WITH MOVE N'TradeBase' TO N'D:\SQLData\TradeBase.mdf',
MOVE N'TradeBase_log' TO N'D:\SQLData\TradeBase_log.ldf',
REPLACE, RECOVERY, STATS = 10;

Параметр RECOVERY переводит базу в рабочее состояние после наката — именно он нужен в большинстве случаев. NORECOVERY оставляет базу в состоянии восстановления и применяется только если вы планируете докатывать дополнительные бэкапы журнала. STATS = 10 выводит прогресс каждые 10 процентов, что удобно для больших файлов.

Если команда завершается ошибкой «logical file is not part of database», проверьте точность логических имён из FILELISTONLY — они чувствительны к регистру и пробелам. Ошибка о том, что база используется, означает активные подключения: завершите сеансы или добавьте перед RESTORE перевод базы в SINGLE_USER с ROLLBACK IMMEDIATE.

Настройте базу после восстановления

Восстановленная база часто содержит пользователей SQL, «потерянных» на новом сервере: логины существуют в базе, но не связаны с серверными учётными записями. Если сервер 1С подключается к СУБД под отдельным логином SQL, создайте его на сервере и привяжите к пользователю базы, либо используйте sp_change_users_login или ALTER USER для сопоставления.

Проверьте модель восстановления базы. Если бэкап снят с сервера, где стояла модель Full, а на новом сервере нет регламентного бэкапа журнала, журнал транзакций будет расти бесконечно. Для тестовых и небольших рабочих баз обычно достаточно модели Simple. Также имеет смысл обновить статистику и перестроить индексы, если база переехала с заметно другой конфигурации железа.

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

Зарегистрируйте базу в 1С и проверьте результат

Сама по себе база в SQL Server ещё не видна пользователям. Откройте консоль кластера серверов 1С и создайте новую информационную базу, указав тип СУБД MS SQL Server, имя сервера СУБД, имя восстановленной базы и учётные данные для подключения. Если сервера 1С нет (файловый режим не подходит для SQL-базы), добавьте базу через диалог запуска 1С с параметрами подключения напрямую.

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

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

Типичные ошибки и как их избежать

Отдельно стоит сказать о битых бэкапах. Если файл повреждён, RESTORE завершится ошибкой контрольной суммы. Иногда помогает опция CONTINUE_AFTER_ERROR, но восстановленная таким способом база может содержать повреждённые данные — её следует проверить командой DBCC CHECKDB и использовать только как временное решение. Регулярно проверяйте свои бэкапы тестовым восстановлением: копия, которую никогда не пытались развернуть, не считается надёжной.

Если база очень большая и время восстановления критично, учитывайте, что сжатые бэкапы (WITH COMPRESSION) разворачиваются дольше при прочих равных, а скорость сильно зависит от дисковой подсистемы. Планируйте окно обслуживания с запасом.

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