Выгрузка и резервная копия базы 1С 8.3: от файла .dt до бэкапа SQL

Дамп базы 1С делают двумя разными способами, и путают их постоянно. Для файловой базы это выгрузка в файл .dt через Конфигуратор: меню Администрирование → Выгрузить информационную базу…. Для клиент-серверной базы правильный бэкап снимают средствами СУБД — MS SQL Server или PostgreSQL, а не выгрузкой из 1С.

Разница принципиальная. Файл .dt — это логическая выгрузка всех данных платформой, она требует монопольного доступа и всех выгоняет из базы. Бэкап СУБД снимается на горячую, пользователи продолжают работать. Ниже — как сделать резервную копию в каждом из вариантов, как проверить, что она живая, и как настроить автоматику, чтобы не делать это руками.

Какой способ выбрать под вашу базу

Сначала определите, какая у вас база. Если 1С работает с локального файла или из сетевой папки и вы видите файл 1Cv8.1CD — это файловый вариант. Если база запускается с сервера 1С и лежит в MS SQL или PostgreSQL — клиент-серверный.

Файл .dt универсален: его можно загрузить в базу любого типа и даже перенести с SQL на файловый вариант. Но на больших базах (десятки гигабайт) выгрузка идёт часами и требует всех выгнать. Поэтому на рабочих клиент-серверных базах его используют как переносную копию, а регулярный бэкап отдают СУБД.

Коротко разница между способами выглядит так:

Переносимость — только у .dt. Остальные способы снимают копию «как есть» и восстанавливаются там же, откуда сняты: бэкап MS SQL не развернуть в PostgreSQL и наоборот.

Что проверить перед выгрузкой

Перед тем как снимать копию, стоит потратить пять минут на подготовку — иначе рискуете сохранить уже повреждённые данные.

Для файловой базы перед выгрузкой полезно прогнать chdbfl.exe — утилиту проверки физической целостности файла 1Cv8.1CD. Она лежит в каталоге bin установленной платформы. Если она нашла и исправила ошибки, делайте дамп уже после этого — так в копию попадут здоровые данные.

Выгрузка файловой базы в файл .dt

Это самый частый способ для небольших баз. Он не зависит от того, где лежит база, и даёт один переносимый файл.

1. Закройте 1С:Предприятие на всех компьютерах, где открыта эта база.
2. Запустите базу в режиме Конфигуратор (в окне запуска выберите базу и нажмите кнопку Конфигуратор).
3. Откройте меню Администрирование → Выгрузить информационную базу….
4. Укажите папку и имя файла, например baza_2026-10-07.dt.
5. Нажмите Сохранить и дождитесь сообщения об успешной выгрузке.

Готовый .dt — это и есть дамп: один файл, который содержит и конфигурацию, и все данные.

Восстановление идёт зеркально: Администрирование → Загрузить информационную базу…, выбираете .dt и подтверждаете. При загрузке все текущие данные базы будут заменены содержимым файла — убедитесь, что грузите копию в правильную, а не в рабочую базу.

Выгрузка в .dt и копия 1Cv8.1CD решают разные задачи. Файл .dt сжат и переносим — его удобно отправить коллеге или залить на другой сервер. Копия 1Cv8.1CD создаётся за секунды простым копированием и разворачивается мгновенно (достаточно подложить файл обратно), но весит столько же, сколько сама база, и несёт в себе все накопленные «хвосты». Для ежедневного бэкапа небольшой базы удобнее копия файла, для архива и переноса — .dt.

Путь каталога с базой видно в окне запуска 1С: выделите базу и посмотрите строку внизу окна — там указан полный путь к папке, в которой и лежит 1Cv8.1CD.

Резервная копия клиент-серверной базы

Для баз на сервере 1С выгрузка в .dt остаётся доступной (тот же пункт в Конфигураторе), но как регулярный бэкап она неудобна: медленная и требует монопольного доступа. Основную копию снимают на уровне СУБД.

MS SQL Server. Копию делают через SQL Server Management Studio (SSMS) или командой T-SQL. Базовый вариант:

BACKUP DATABASE [ИмяБазы]
  TO DISK = N'D:\backup\baza.bak'
  WITH INIT, COMPRESSION;

WITH INIT перезаписывает файл, COMPRESSION сжимает бэкап (доступно в редакциях Standard и выше). Для регулярности в SSMS настраивают план обслуживания (Maintenance Plan) с задачей Back Up Database.

PostgreSQL. Логическую копию одной базы снимают утилитой pg_dump:

pg_dump -U postgres -F c -f /backup/baza.backup ИмяБазы

Ключ -F c задаёт сжатый custom-формат, который восстанавливается через pg_restore. Для копии всего кластера целиком используют pg_basebackup. Пароль задают через переменную окружения PGPASSWORD или файл .pgpass, чтобы не светить его в скрипте.

Восстановление идёт обратными командами. Для MS SQL:

RESTORE DATABASE [ИмяБазы_test]
  FROM DISK = N'D:\backup\baza.bak'
  WITH MOVE N'ЛогДанных' TO N'D:\sql\baza_test.mdf',
       MOVE N'ЛогЛога'   TO N'D:\sql\baza_test.ldf',
       REPLACE;

Для PostgreSQL дамп, снятый в custom-формате, разворачивают через pg_restore -U postgres -d ИмяБазы_test /backup/baza.backup. После восстановления базу подключают к серверу 1С как новую информационную базу и открывают для проверки.

Как убедиться, что копия рабочая

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

• Файл .dt. Создайте пустую тестовую базу и загрузите в неё дамп через Администрирование → Загрузить информационную базу…. Если база открылась в режиме 1С:Предприятие и документы на месте — копия валидна.
• Бэкап SQL. Восстановите .bak в отдельную базу (RESTORE DATABASE … WITH MOVE), подключите её как тестовую информационную базу 1С и откройте.
• Бэкап PostgreSQL. Разверните дамп через pg_restore в новую базу и так же подключите к серверу 1С.

После разворота прогоните Администрирование → Тестирование и исправление… в Конфигураторе восстановленной базы в режиме «только проверка» — это подтвердит логическую целостность данных.

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

Отдельно стоит проверять не только разворачиваемость, но и свежесть. Бэкап недельной давности формально рабочий, но если он создавался по расписанию, а задание неделю назад упало с ошибкой, свежих копий у вас нет. Поэтому автоматические задания должны присылать уведомление об успехе или сбое — на почту или в мессенджер. Молчание планировщика не означает, что всё хорошо; чаще оно означает, что задание вообще не запускалось.

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

Автоматизация: бэкап по расписанию

Руками дамп забывают делать. Поэтому резервное копирование автоматизируют, а результат складывают по датам.

Встроенное средство в файловой базе. В типовых конфигурациях (Бухгалтерия 3.0, ЗУП 3.1 и других на управляемых формах) для файлового варианта есть пункт Администрирование → Обслуживание → Резервное копирование и восстановление. Там настраивается автоматическое создание .dt — по расписанию или при завершении работы. Для небольших баз это самый простой путь, ничего программировать не нужно.

Пакетный запуск Конфигуратора. Для выгрузки без участия человека платформа умеет работать из командной строки:

"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" DESIGNER ^
 /F"C:\bases\buh" /N"Админ" /P"пароль" ^
 /DumpIB "D:\backup\buh_%date%.dt"

Параметр /DumpIB выгружает базу, /RestoreIB — загружает обратно. Для серверной базы вместо /F указывают /S"сервер\база". Такой .bat ставят в Планировщик заданий Windows на ночное время.

Скрипты СУБД. Для MS SQL расписание задаёт план обслуживания или задание Агента SQL Server. Для PostgreSQL pg_dump запускают из cron (Linux) или Планировщика заданий (Windows).

Что бы вы ни выбрали, настройте ротацию: храните, например, последние 7 ежедневных и 4 еженедельных копии, старые удаляйте. Иначе диск забьётся дампами за полгода.

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

И ещё одно про имена файлов. Включайте в имя дату, а лучше — дату и время: buh_2026-10-07_0300.dt. Так копии не затирают друг друга, и по списку сразу видно, за какое число свежий бэкап. В .bat для этого подставляют системные переменные %date% и %time%, в скриптах Linux — вывод date.

Типичные ошибки при создании дампа

Эти промахи встречаются чаще всего — и каждый из них превращает бэкап в бесполезный файл.

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