Как выгрузить и загрузить базу 1С в dt-файл: конфигуратор, командная строка, ibcmd

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

Что такое dt-файл и когда выгрузка информационной базы действительно нужна

Файл с расширением dt — это переносимый снимок информационной базы 1С: конфигурация, данные, пользователи, всё, что лежит внутри. Его делает сама платформа, а не СУБД, поэтому один и тот же dt можно загрузить и в файловую базу, и в клиент-серверную на PostgreSQL или MS SQL. Именно на этом держится самый частый сценарий, с которым ко мне приходят: перенос базы с одного режима на другой. Если вам нужна помощь с такими переездами, мы в АйТи-Фреш занимаемся сопровождением 1С и серверов под неё, но почти всё из этой статьи вы вполне сделаете сами.

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

Почему так? Выгрузка в dt проходит через платформу, она медленнее копии на уровне СУБД и требует, чтобы в базе никто не работал. Для базы в 3–5 ГБ это терпимо, ночью вы этого не заметите. Для базы на 200 ГБ это час-два простоя, и каждое такое окно придётся с кем-то согласовывать. Поэтому моя схема для клиентов такая: основной бэкап делает СУБД, а dt я использую как страховку и как формат переноса. Про автоматизацию ночной выгрузки и ротацию копий я подробно писал отдельно, здесь же разберём сам механизм выгрузки и загрузки.

• Нужен dt: перенос между файловым и клиент-серверным режимом, смена СУБД, переезд на другой сервер, тестовая копия, передача базы подрядчику.
• Не нужен dt как единственный бэкап большой рабочей базы: он требует остановки работы пользователей и медленнее, чем средства СУБД.
• Всегда нужен dt: перед обновлением платформы или конфигурации, как точка возврата, если у вас небольшая база и ночное окно.

Как выгрузить базу 1С в dt через конфигуратор

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

Главное условие — в базе не должно быть других пользователей. Если в ней кто-то сидит, конфигуратор не получит монопольного доступа и выгрузка не пойдёт. На практике это самая частая причина, по которой «не выгружается»: один бухгалтер ушёл на обед и оставил открытый сеанс. Для клиент-серверной базы список сеансов смотрите в консоли кластера и завершайте их там. Для файловой — просто попросите всех выйти или проверьте, кто держит файл блокировки.

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

Выгрузка и загрузка dt из командной строки: ключи /DumpIB и /RestoreIB

Когда выгрузка нужна по расписанию, интерфейс не подходит. Конфигуратор умеет работать в пакетном режиме: вы запускаете 1cv8.exe с параметром DESIGNER, передаёте ключи, и после выполнения действий конфигуратор сам закрывается. За выгрузку отвечает ключ /DumpIB, за загрузку — /RestoreIB. Подключение к базе задаётся ключом /F для файловой базы (путь к каталогу) или /S для клиент-серверной (сервер\имя_базы), а пользователь и пароль — ключами /N и /P. Журнал результата пишется в файл, который указан в /Out. Для запуска из планировщика я всегда добавляю /DisableStartupDialogs и /DisableStartupMessages: без них платформа может показать окно с вопросом, и задание будет висеть до утра, ожидая нажатия кнопки, которую никто не нажмёт. Точный набор ключей и их регистр проверяйте по справке своей версии платформы: у разных релизов бывают нюансы.

Ниже скрипт, который я ставлю в планировщик Windows на сервере 1С. Он запускает выгрузку, ждёт завершения через Start-Process с параметрами -Wait и -PassThru (так мы получаем объект процесса и можем прочитать код возврата), затем проверяет, что файл существует и не пустой, и считает хеш. Get-FileHash по умолчанию использует SHA256, этого достаточно. Пароль я не пишу в скрипт, а беру из переменной окружения учётной записи, под которой работает задание. Путь к платформе подставьте свой.

$exe  = 'C:\Program Files\1cv8\<версия>\bin\1cv8.exe'
$dt   = "D:\backup\kennel_$(Get-Date -Format yyyyMMdd_HHmm).dt"
$log  = 'D:\backup\dump.log'
$argLine = "DESIGNER /DisableStartupDialogs /DisableStartupMessages /S srv1c\kennel /N backup_user /P `"$env:ONEC_PWD`" /DumpIB `"$dt`" /Out `"$log`""
$p = Start-Process -FilePath $exe -ArgumentList $argLine -Wait -PassThru
if ($p.ExitCode -ne 0 -or -not (Test-Path $dt) -or (Get-Item $dt).Length -lt 1MB) {
    throw "Выгрузка не удалась, смотрите $log"
}
Get-FileHash $dt | Format-List

Обратите внимание на кавычки: аргументы передаются одной строкой, а пути с пробелами нужно экранировать. Документация PowerShell отдельно советует передавать в -ArgumentList одну строку со всеми аргументами и нужными кавычками. Это место, где у новичков ломается больше всего, и вместо выгрузки платформа получает обрезанный путь.

Загрузка выглядит так же, только с ключом /RestoreIB. Я не автоматизирую её в рабочем контуре, потому что ошибка в имени базы приведёт к замене не той базы. А вот для регулярного обновления тестовой копии из рабочей базы скрипт загрузки очень удобен: выгрузили ночью, загрузили в тест, утром у разработчика свежие данные.

$argLine = "DESIGNER /DisableStartupDialogs /DisableStartupMessages /S srv1c\kennel_test /N backup_user /P `"$env:ONEC_PWD`" /RestoreIB `"$dt`" /Out `"D:\backup\restore.log`""
Start-Process -FilePath $exe -ArgumentList $argLine -Wait -PassThru

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

Чем dt отличается от дампа PostgreSQL и что такое ibcmd

Эти два формата путают чаще всего, поэтому разведу по пунктам. Дамп PostgreSQL, который делает pg_dump, — это копия самой базы данных на уровне СУБД. Он быстрый, его можно снимать, пока пользователи работают, и документация PostgreSQL подтверждает, что pg_dump делает согласованную выгрузку даже при одновременном использовании базы и не блокирует читателей и писателей. Но восстановить такой дамп можно только в PostgreSQL, и 1С в этот момент ничего о нём не знает.

Файл dt, наоборот, формат платформы. Он переносим между режимами и СУБД, но делается дольше и требует остановки работы. Вывод простой: dt для переноса и контрольной точки, дамп СУБД для ежедневного бэкапа. Пример для PostgreSQL в архивном формате, который потом восстанавливается через pg_restore:

pg_dump -Fc -f /backup/kennel.dump kennel
createdb kennel_test
pg_restore -d kennel_test /backup/kennel.dump

Формат custom (-Fc) сжат по умолчанию, и именно его рекомендует документация для восстановления через pg_restore. Но и сама документация PostgreSQL оговаривает, что pg_dump подходит не для всех сценариев регулярного бэкапа боевых баз, и отсылает к главе про резервное копирование. Для серьёзных объёмов мы строим резервное копирование PostgreSQL через Barman или pgBackRest, а dt остаётся вторым уровнем защиты.

Третий способ выгрузить dt — утилита администрирования ibcmd, которая работает с базой напрямую, без запуска конфигуратора. Это удобно на Linux-сервере, где графического конфигуратора нет. Подробности такие: в руководстве администратора 1С сказано, что перед выгрузкой нужно убедиться, что к базе нет подключений, иначе нарушится целостность файла dt. Это важно, потому что в сети гуляют примеры, где утверждается обратное. Имена параметров подключения к СУБД у ibcmd в разных источниках записаны по-разному, поэтому не копируйте команды из форумов, а сверяйтесь со справкой своей версии платформы:

ibcmd infobase dump --help

И ещё один практический момент. Если вы собираетесь переносить файловую базу на сервер, сначала прочитайте нашу статью про перенос файловой базы 1С на PostgreSQL: dt там — всего один шаг из нескольких, и остальные не менее важны.

Почему выгрузка или загрузка dt не проходит: ошибки, которые я вижу чаще всего

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

Вторая причина — место на диске. Dt обычно в несколько раз меньше базы, потому что он сжат и не содержит индексов, и это вводит в заблуждение. Выгрузка влезает в свободные 2 ГБ, а загрузка нет: при загрузке платформа разворачивает базу в полный размер, плюс нужно место под журналы СУБД и временные файлы. Считайте так: на загрузку нужно свободного места не меньше, чем занимает развёрнутая база, с запасом в 30–50 процентов. Для файловой базы сюда же добавьте каталог временных файлов пользователя, под которым запущено задание.

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

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

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

Как проверить, что dt-файл не битый, до того как он понадобится

Файл, который ни разу не загружали, — не бэкап, а надежда. Я проверяю dt тремя способами, от простого к надёжному. Первый — проверка по размеру и дате: файл не пустой, он свежий, и его размер отличается от вчерашнего на разумную величину. Это ловит самые грубые сбои. Второй — контрольная сумма: сразу после выгрузки считаем хеш (в PowerShell это Get-FileHash, по умолчанию SHA256) и после копирования на другое хранилище считаем заново. Если хеши не совпали, файл повредился при копировании. Это защищает от проблем сети и флешек, но не говорит, что внутри dt вообще корректная база.

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

Хранить проверенные файлы стоит по правилу «минимум две копии на разных носителях и одна вне офиса». Обычная ошибка малых компаний — оставить dt на том же сервере, где крутится сама база. Диск умер — и база, и её копия исчезли вместе. Копируйте файл хотя бы на сетевую папку с NAS и в облачное хранилище, а сроки хранения выбирайте по своему допустимому окну потери данных, а не по тому, сколько влезло на диск.

Разбор из практики: питомник «Чистая порода» переезжает с файловой базы на сервер

Питомник животных «Чистая порода», 15 рабочих мест. Бухгалтерия, учёт племенных животных и продаж щенков в одной файловой базе 1С на сетевой папке старого сервера. База весила около 3,4 ГБ, и к концу года работа в ней тормозила так, что отчёты ждали по несколько минут. Решение было очевидным: перенести базу на клиент-серверный вариант с PostgreSQL на новом сервере. Мост между двумя режимами — dt.

Я разбил переезд на два этапа. Сначала репетиция в рабочее время на копии: выгрузка dt из конфигуратора заняла около 11 минут, файл получился примерно 520 МБ. При первой загрузке в тестовую клиент-серверную базу процесс остановился: на диске сервера оставалось около 2 ГБ свободного места, а развёрнутой базе требовалось больше. Файл dt лёгкий, но база после загрузки заняла в разы больше. Мы добавили диск под данные PostgreSQL и повторили загрузку, она прошла примерно за 38 минут. Эту цифру я потом использовал для планирования окна переезда.

Второй этап — боевой переезд в субботу. Я попросил бухгалтера выйти из базы, проверил отсутствие сеансов, сделал свежую выгрузку и отдельно скопировал папку с файловой базой. Загрузка в рабочую серверную базу прошла за те же 38–40 минут, после чего я проверил входы под разными ролями, а старую файловую базу убрал из списка баз у пользователей, чтобы никто по привычке не начал работать в ней. Тестовую копию с репетиции мы держали с отключёнными регламентными заданиями с первого дня, чтобы она не отправляла письма покупателям. Общий простой составил около двух часов, из которых большая часть пришлась на копирование и проверку. После переезда построение тех же отчётов ускорилось с нескольких минут до десятков секунд, а ночную выгрузку dt мы поставили по расписанию в 23:00 как вторую линию защиты рядом с дампом PostgreSQL. Итог: переезд прошёл в одно окно, откат не понадобился, а папка со старой базой хранилась ещё месяц на всякий случай.

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