Файл BAK: как открыть в 1С и восстановить базу

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

До начала работ важно точно определить, что за файл у вас в руках. BAK — это расширение «по умолчанию» у многих программ, и встречаются три ситуации: полноценный бэкап SQL Server, просто переименованная копия файловой базы 1Cv8.1CD и резервная копия, созданная сторонним ПО. От этого зависит весь дальнейший сценарий. Ниже разобраны способы определить тип файла и пошаговые инструкции восстановления для каждого случая.

Как определить, что за BAK-файл у вас в руках

Первый шаг — посмотреть на размер и происхождение файла. Если файл находится в папке резервных копий SQL Server (часто это каталог Backup внутри каталога установки SQL Server или отдельное сетевое хранилище, куда пишет план обслуживания), почти наверняка это дамп SQL Server. Такие файлы обычно называются по шаблону «ИмяБазы_backup_дата_время.bak».

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

Третий вариант — BAK, созданный сторонними системами резервного копирования (Veeam, Acronis, штатные скрипты). Такие файлы могут иметь собственный внутренний формат, и восстанавливать их нужно средствами той же программы. Признак — наличие установленного ПО резервного копирования и заданий в его расписании.

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

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

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

Если графический интерфейс недоступен, используйте T-SQL. Перед восстановлением полезно посмотреть состав бэкапа командой RESTORE FILELISTONLY — она покажет логические имена файлов, которые нужны для корректного RESTORE с параметром MOVE.

RESTORE FILELISTONLY FROM DISK = 'D:\Backups\base_backup.bak';
RESTORE DATABASE MyBase FROM DISK = 'D:\Backups\base_backup.bak'
WITH MOVE 'DataLogicalName' TO 'D:\SQLData\MyBase.mdf',
MOVE 'LogLogicalName' TO 'D:\SQLData\MyBase_log.ldf', REPLACE;

1. 1
   Определите тип файла: дамп SQL Server, копия 1Cv8.1CD или формат стороннего ПО
2. 2
   Восстановите базу на SQL Server через SSMS или командой RESTORE
3. 3
   Проверьте, что база в состоянии ONLINE и доступна
4. 4
   Создайте запись информационной базы в консоли кластера 1С или добавьте базу в список
5. 5
   Откройте базу в конфигураторе и выполните тестирование целостности

Подключение восстановленной базы к 1С

После восстановления базы на SQL Server её нужно «увидеть» со стороны 1С. Если база восстановлена на тот же сервер под тем же именем и запись в консоли кластера уже существует — ничего дополнительно делать не нужно, пользователи просто заходят как обычно.

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

Для файлового варианта (когда BAK оказался переименованной копией 1Cv8.1CD) всё проще: переименуйте файл обратно в 1Cv8.1CD, поместите его в отдельный каталог и добавьте базу в список информационных баз стартера 1С как файловую, указав этот каталог.

Чем BAK отличается от DT и почему это важно

Путаница между форматами — главный источник проблем. Файл .dt создаётся штатной выгрузкой из конфигуратора («Администрирование → Выгрузить информационную базу») и загружается обратно той же командой. Это переносимый формат: из него можно развернуть базу и на файловом, и на клиент-серверном варианте, независимо от СУБД.

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

Проверка восстановленной базы и типичные ошибки

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

Типовые ошибки при восстановлении: попытка восстановить BAK на SQL Server более старой версии, чем тот, где создавалась копия (ошибка несовместимости, обратной совместимости нет); нехватка места на диске под разворачиваемые файлы; неверные пути к файлам данных при переносе на другой сервер; отсутствие прав у учётной записи сервера 1С. Отдельный случай — попытка «открыть» BAK двойным щелчком или подсунуть его конфигуратору как dt: платформа такой файл не примет.

Контрольные точки результата

Итоговая проверка занимает несколько минут и избавляет от неприятных сюрпризов. Убедитесь, что база на SQL Server находится в состоянии ONLINE, запись в консоли кластера указывает именно на неё, а пользователи могут войти. Сверьте даты последних документов с ожидаемой датой бэкапа — это самый быстрый способ понять, что восстановлена именно та копия.

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