Как восстановить базу 1С из bak-файла

Файл с расширением .bak — это резервная копия базы данных Microsoft SQL Server, в которой хранится клиент-серверная информационная база 1С. Восстановление из такого файла — стандартная операция при переносе базы на другой сервер, откате после неудачного обновления или аварийном восстановлении. Важно понимать: .bak — это не файловая копия базы 1С (не .dt и не каталог с 1Cv8.1CD), поэтому открыть его напрямую в конфигураторе нельзя.

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

Ниже разобран полный порядок действий для связки 1С:Предприятие + MS SQL Server, а также вариант восстановления через T-SQL, отличия от восстановления из .dt и типичные ошибки, из-за которых база не поднимается.

Что такое bak-файл и когда он используется в 1С

Расширение .bak по умолчанию получают полные резервные копии, созданные командой BACKUP DATABASE в SQL Server — вручную, через план обслуживания или сторонними средствами резервного копирования. Внутри файла находится снимок базы данных: таблицы, индексы, хранимые процедуры и служебные структуры, в которых 1С хранит конфигурацию, данные и настройки.

Такой способ резервного копирования применяется только в клиент-серверном варианте работы 1С. Если база файловая (лежит в каталоге в виде файла 1Cv8.1CD), то .bak у неё не бывает — там используются копии каталога или выгрузка в .dt. Поэтому первый шаг перед восстановлением — убедиться, что у вас действительно клиент-серверная база и копия сделана именно из SQL Server.

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

Прежде чем запускать восстановление, нужно сопоставить версии и подготовить окружение. Главное ограничение: SQL Server не умеет восстанавливать копии, созданные на более новой версии сервера. База, скопированная на SQL Server 2019, не поднимется на SQL Server 2016 — ошибка будет выдана сразу на этапе чтения заголовка файла. Обратная совместимость (со старой версии на новую) работает.

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

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

Основной инструмент — SQL Server Management Studio (SSMS). Подключитесь к экземпляру SQL Server под учётной записью с правами на восстановление баз (sysadmin или dbcreator). Затем выполните следующие шаги.

1. 1
   Откройте SSMS и подключитесь к нужному экземпляру SQL Server
2. 2
   Щёлкните правой кнопкой по узлу «Базы данных» и выберите «Восстановить базу данных»
3. 3
   В поле «Источник» выберите «Устройство» и укажите путь к .bak-файлу
4. 4
   Проверьте имя целевой базы — при необходимости задайте новое, чтобы не затереть рабочую
5. 5
   На вкладке «Файлы» проверьте пути размещения mdf и ldf — диски должны существовать и иметь свободное место
6. 6
   На вкладке «Параметры» при восстановлении поверх существующей базы включите «Перезаписать существующую базу (WITH REPLACE)»
7. 7
   Нажмите OK и дождитесь сообщения об успешном завершении

Обратите внимание на вкладку «Файлы»: SSMS по умолчанию подставляет пути, зашитые в резервную копию, то есть пути исходного сервера. Если на целевом сервере нет диска с такой буквой или каталога, восстановление упадёт с ошибкой доступа. Исправьте пути на реально существующие.

После завершения база появится в списке баз данных в состоянии «В сети» (Online). Если статус «Восстановление…» (Restoring), значит копия была восстановлена с параметром NORECOVERY — это нужно для цепочек разностных копий, но для одиночной полной копии следует выбирать RECOVERY.

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

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

RESTORE FILELISTONLY FROM DISK = 'D:\Backups\base1c.bak';
GO
RESTORE DATABASE [MyBase1C]
FROM DISK = 'D:\Backups\base1c.bak'
WITH MOVE 'DataFile' TO 'E:\SQLData\MyBase1C.mdf',
     MOVE 'LogFile'  TO 'E:\SQLData\MyBase1C.ldf',
     REPLACE, RECOVERY;
GO

Параметр REPLACE нужен только при восстановлении поверх существующей базы — без него SQL Server откажется перезаписывать данные. Имена логических файлов (в примере DataFile и LogFile) возьмите из вывода FILELISTONLY, они у каждой базы свои.

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

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

В диалоге создания укажите: тип СУБД — MS SQL Server, имя сервера баз данных, имя базы данных — точно такое, как при восстановлении в SSMS, и пользователя СУБД с правами на эту базу. Галочку «Создать базу данных в случае её отсутствия» ставить не нужно — база уже существует, иначе есть риск получить пустую структуру вместо данных.

Если база регистрируется на том же кластере параллельно с рабочей (например, для тестирования), обязательно задайте другое имя ИБ в кластере и другое имя базы данных в SQL — иначе два объекта кластера будут ссылаться на одни данные, что ведёт к конфликтам блокировок и рассинхронизации.

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

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

Для тестовых копий после восстановления рекомендуется отключить регламентные задания, которые могут «выстрелить» в продуктив: обмены с другими системами, отправку почты, выгрузки в банк. Это делается в настройках ИБ в консоли кластера (блокировка регламентных заданий) либо внутри конфигурации.

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

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

Альтернативы: когда вместо bak нужен dt или другой способ

Выбор зависит от задачи: аварийное восстановление на том же сервере быстрее всего выполнить из .bak, перенос базы разработчику или в другое окружение с другой СУБД — через .dt, а миграцию между инфраструктурами иногда проще сделать переносом файлов базы с последующим attach.

Часто задаваемые вопросы