Дампы 1С: где находятся файлы выгрузки базы

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

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

Что именно считается дампом в 1С

Под термином «дамп» в контексте 1С скрываются три разных объекта. Первый — файл выгрузки информационной базы .dt, который создаётся через конфигуратор и содержит и данные, и конфигурацию. Второй — резервная копия базы данных, сделанная средствами СУБД: для MS SQL это файлы .bak, для PostgreSQL — файлы, созданные pg_dump. Третий — простое копирование файла 1Cv8.1CD, когда база работает в файловом режиме.

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

Где искать файл выгрузки .dt

При выгрузке через конфигуратор платформа предлагает диалог сохранения файла, и путь зависит от того, что выбрал пользователь. Чаще всего .dt оказывается в папках «Документы», «Загрузки», на рабочем столе или в специально созданном каталоге вроде C:\Backup1C. Платформа запоминает последний использованный путь, поэтому повторная выгрузка по умолчанию предложит ту же папку.

Если выгрузку делал другой сотрудник или давно, быстрее всего воспользоваться поиском Windows: откройте проводник на уровне диска и выполните поиск по маске *.dt, отсортировав результат по дате изменения. На сервере терминалов проверяйте профили всех пользователей, которые могли запускать конфигуратор, — файл мог сохраниться в чужом профиле.

Отдельный случай — автоматизированная выгрузка через командную строку конфигуратора с параметром /DumpIB. Там путь жёстко прописан в скрипте или bat-файле, поэтому сначала найдите сам скрипт (обычно он лежит рядом с заданием планировщика задач Windows) и посмотрите, какой каталог в нём указан.

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F"C:\Bases\Trade" /N"Админ" /P"пароль" /DumpIB"D:\Backup\trade_%date%.dt"

Где находятся бэкапы в клиент-серверном режиме

В клиент-серверной архитектуре дампы создаются и хранятся на стороне сервера СУБД, а не сервера 1С. Для MS SQL Server стандартный каталог резервных копий по умолчанию — подпапка Backup внутри каталога экземпляра, например C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Backup. Точный путь зависит от версии и имени экземпляра.

Для PostgreSQL дампы pg_dump сохраняются туда, куда указывает команда или скрипт, — единого каталога по умолчанию нет. Ищите задания в cron (Linux) или планировщике задач (Windows), а также скрипты обслуживания, которые администратор настраивал при развёртывании.

Если бэкап настроен через план обслуживания (maintenance plan) в SQL Server Management Studio, путь хранения указан прямо в свойствах задачи Backup Database. Откройте SSMS, разверните узел Management → Maintenance Plans и проверьте настройки существующих планов — там же видно расписание и срок хранения копий.

1. 1
   Уточните, какая СУБД используется: откройте свойства базы в консоли кластера 1С или спросите администратора
2. 2
   Для MS SQL откройте SSMS и проверьте Management → Maintenance Plans и историю заданий агента SQL Server
3. 3
   Проверьте стандартный каталог Backup внутри папки экземпляра SQL Server
4. 4
   Для PostgreSQL найдите скрипт бэкапа в планировщике и посмотрите путь в команде pg_dump
5. 5
   Выполните поиск по дискам сервера по маскам <em>.bak, </em>.dt, *.backup с сортировкой по дате

Файловый режим: где лежит сама база и её копии

В файловом режиме вся база — это каталог с файлом 1Cv8.1CD. Путь к нему виден в окне запуска 1С: выделите базу в списке, и внизу окна отобразится строка вида File="D:\1C_Bases\Trade". Это и есть расположение «живых» данных.

Резервная копия файловой базы — это либо .dt, либо архив/копия всего каталога базы. Многие организации настраивают копирование папки базы по расписанию на сетевой диск или в облачное хранилище. Проверьте планировщик задач Windows на предмет заданий с robocopy, xcopy или архиваторами — там будет указан и источник, и приёмник копий.

Сетевые расположения — частая ловушка: папка с бэкапами может быть подключена как сетевой диск только у конкретного пользователя или отключена вовсе. Если диск недоступен, проверьте UNC-путь напрямую (\\server\backup) и права доступа.

Как проверить, что найденный дамп рабочий

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

Надёжная проверка .dt — тестовая загрузка в пустую базу на отдельном компьютере или в отдельный каталог. Создайте пустую базу без конфигурации, откройте конфигуратор и выполните «Загрузить информационную базу». Если загрузка завершилась без ошибок и база открывается в режиме предприятия — дамп исправен.

Для бэкапов SQL Server используйте команду RESTORE VERIFYONLY — она проверяет читаемость файла без фактического восстановления. Полный тест — восстановление в базу с другим именем на том же или тестовом сервере.

Как настроить понятное и надёжное хранение дампов

Чтобы вопрос «где лежит дамп» больше не возникал, закрепите единый каталог для резервных копий — например, выделенный диск на сервере с папкой вида D:\Backup1C\ИмяБазы. Пропишите этот путь в скриптах автоматической выгрузки и задокументируйте его во внутренней инструкции.

Добавляйте дату в имя файла (trade_2026-05-17.dt), чтобы копии не затирали друг друга, и настройте автоматическое удаление файлов старше заданного срока — иначе диск рано или поздно заполнится, и задание бэкапа начнёт падать молча.

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

Когда самостоятельных действий недостаточно

Если рабочая база повреждена, а актуального дампа нет, не предпринимайте поспешных действий: не запускайте тестирование и исправление с включёнными флагами исправления без копии повреждённого файла и не перезаписывайте диск новыми данными. Любая запись снижает шансы на восстановление данных специализированными средствами.

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

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