Как выгрузить базу данных из SQL Server для 1С

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

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

Ниже разобраны оба способа с конкретными действиями, условиями выбора, проверкой результата и типичными ошибками, которые приводят к потере данных или нерабочим копиям.

Определитесь с форматом выгрузки: .bak или .dt

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

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

Как сделать резервную копию через SQL Server Management Studio

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

Щёлкните по базе правой кнопкой мыши, выберите «Задачи» → «Создать резервную копию». В окне настройки укажите тип копии «Полная», проверьте путь назначения и при необходимости замените его на диск с достаточным свободным местом. Размер .bak-файла обычно заметно меньше размера данных за счёт исключения свободного пространства, но подстрахуйтесь запасом. Нажмите «ОК» и дождитесь сообщения об успешном завершении.

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

1. 1
   Подключитесь к серверу в SSMS под учётной записью с правами на бэкап
2. 2
   Найдите базу в списке «Базы данных»
3. 3
   Правый клик → «Задачи» → «Создать резервную копию»
4. 4
   Выберите тип «Полная» и укажите путь к файлу .bak
5. 5
   Нажмите «ОК» и дождитесь сообщения об успехе
6. 6
   Проверьте, что файл создан и имеет ненулевой размер

Тот же бэкап через T-SQL

Для автоматизации и включения в скрипты удобнее команда BACKUP DATABASE. Она выполняется в окне запроса SSMS и легко встраивается в задания агента SQL Server или планировщик Windows.

BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backups\MyBase1C_full.bak' WITH COMPRESSION, CHECKSUM;

Параметр COMPRESSION уменьшает размер файла (поддерживается не во всех редакциях SQL Server), CHECKSUM добавляет проверку целостности при записи. Путь указывается относительно сервера, где работает SQL Server, а не вашего рабочего компьютера — частая причина ошибок «не найден путь».

Как выгрузить базу в файл .dt через конфигуратор

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

Затем запустите конфигуратор, авторизуйтесь под пользователем с правами администратора и откройте меню «Администрирование» → «Выгрузить информационную базу». Укажите каталог и имя файла, дождитесь окончания процесса. На больших базах прогресс может визуально «замирать» — это нормально, прерывать операцию нельзя.

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

Выгрузка .dt из командной строки

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

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /S"Server\MyBase1C" /N"Администратор" /P"пароль" /DumpIB"D:\Backups\MyBase1C.dt"

Ключ /S задаёт сервер и имя базы, /N и /P — логин и пароль пользователя 1С. Хранить пароль в открытом виде в скрипте небезопасно: ограничьте доступ к файлу скрипта или используйте другие механизмы защиты учётных данных.

Как проверить, что выгрузка удалась

Сам факт появления файла не гарантирует работоспособность копии. Для .bak минимальная проверка — команда RESTORE VERIFYONLY, которая читает файл и подтверждает его целостность без фактического восстановления. Полная проверка — тестовое восстановление в базу с другим именем на том же или тестовом сервере.

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

Типичные ошибки и ограничения

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

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

Особые сценарии: большие базы и переезд на другую СУБД

Если база занимает сотни гигабайт, выгрузка .dt может быть практически невыполнима в разумное время. В этом случае для переноса между серверами SQL Server используйте связку «бэкап на старом сервере → восстановление на новом». Переезд на PostgreSQL или в файловый вариант всё равно потребует .dt, поэтому заранее закладывайте длительное окно обслуживания и тестируйте процедуру на копии.

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

Организация регулярного резервного копирования

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

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

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