BAK: что это за формат в 1С и как восстановить из него базу

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

Чаще всего под «BAK в 1С» понимают один из двух сценариев: копия файловой базы, где переименован файл 1Cv8.1CD, или выгрузка базы MS SQL Server, сделанная средствами SQL Server (команда BACKUP DATABASE). От того, какой именно это случай, зависит способ восстановления — и ошибиться здесь легко.

Правильно определить происхождение файла — ключевая задача до начала любых действий. Восстановление «не тем» способом в лучшем случае завершится ошибкой, в худшем — затрёт рабочую базу. Ниже разберём, как отличить типы BAK-файлов, как безопасно восстановить данные и какие проверки выполнить после.

Что скрывается за расширением .bak

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

Основные варианты происхождения BAK рядом с 1С:

• Переименованный 1Cv8.1CD — копия файловой базы, которую администратор или скрипт сохранил, изменив расширение. Восстанавливается простым переименованием обратно в 1Cv8.1CD.
• Бэкап MS SQL Server — создан командой BACKUP DATABASE или через план обслуживания. Восстанавливается только средствами SQL Server (SSMS), а не конфигуратором 1С.
• Архив сторонней программы — некоторые backup-утилиты (Veeam, Cobian и др.) пишут свои копии с расширением .bak. Формат определяется документацией конкретной программы.
• Автокопия самой 1С — при некоторых операциях (например, тестировании и исправлении с включённой опцией создания копии) платформа сохраняет исходный файл базы с расширением .bak или аналогичным суффиксом.

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

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

Расположение даёт первую подсказку. Файл, лежащий в каталоге файловой базы рядом с папками 1Cv8Log и служебными файлами — почти наверняка переименованный 1Cv8.1CD. Файл в папке вида Backup на диске SQL-сервера или в каталоге, который обслуживает план обслуживания SQL Server — скорее всего бэкап СУБД.

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

Быстрый способ проверить SQL-бэкап без восстановления — выполнить в SSMS команду RESTORE HEADERONLY: она покажет имя исходной базы, дату создания и тип бэкапа, не изменяя никаких данных.

RESTORE HEADERONLY FROM DISK = N'D:\Backup\mybase.bak';

Восстановление файловой базы из BAK

Самый простой сценарий: BAK — это переименованная копия 1Cv8.1CD. Здесь восстановление сводится к возврату правильного имени файлу и подключению базы в списке информационных баз.

1. 1
   Создайте новую пустую папку для восстанавливаемой базы — не работайте в каталоге действующей базы.
2. 2
   Скопируйте (не переместите!) BAK-файл в эту папку.
3. 3
   Переименуйте копию в 1Cv8.1CD.
4. 4
   Откройте окно запуска 1С, нажмите «Добавить» → «Добавление в список существующей информационной базы» и укажите созданную папку.
5. 5
   Запустите базу в режиме конфигуратора и убедитесь, что она открывается без ошибок.
6. 6
   Проверьте актуальность данных: откройте в режиме предприятия несколько последних документов.

Обязательно работайте с копией, а не с оригиналом BAK. Если файл окажется повреждённым или окажется, что это вовсе не база 1С, у вас останется нетронутый исходник для повторной попытки или передачи специалисту.

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

Восстановление клиент-серверной базы из SQL-бэкапа

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

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

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

Чем BAK отличается от DT и что выбрать для копирования

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

Для клиент-серверных баз предпочтителен SQL-бэкап по расписанию плюс периодическая выгрузка DT как независимый контрольный экземпляр. Для файловых баз минимум — регулярное копирование 1Cv8.1CD при закрытых сеансах. Полагаться на один метод рискованно: если единственная копия окажется битой, восстанавливать будет нечего.

Типичные ошибки при работе с BAK

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

Как проверить, что восстановление прошло успешно

Факт открытия базы — необходимое, но недостаточное условие. База может открываться и при этом содержать повреждённые таблицы или неполные данные, особенно если BAK создавался в аварийной ситуации.

Для файловых баз после восстановления рекомендуется запустить утилиту chdbfl.exe (поставляется с платформой) или встроенное тестирование и исправление в режиме проверки физической целостности. Для SQL-баз достаточно штатной проверки целостности средствами СУБД (DBCC CHECKDB) и контрольного открытия в режиме предприятия.

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