Резервная копия 1С: как создать DT, восстановить и проверить базу

Файл DT полезен только тогда, когда его можно загрузить и получить целую рабочую базу. Разбираем выгрузку, восстановление в отдельном контуре, контрольные проверки и место DT в полноценной стратегии резервного копирования.

Что такое файл DT и почему одной выгрузки недостаточно

DT — файл логической выгрузки информационной базы 1С:Предприятие. В него переносится структура конфигурации и данные, чтобы затем загрузить их в пустую информационную базу. Официальная документация 1С описывает команды выгрузки и загрузки информационной базы в Конфигураторе.

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

DT не хранит вашу дисциплину резервирования: кто запускает процедуру, где лежат предыдущие версии, сколько копий сохраняется и как быстро можно вернуться к работе. Эти правила нужны отдельно.

Когда подходит DT, а когда нужна копия СУБД

Для небольшой файловой базы DT удобен перед обновлением, массовой обработкой или переносом в тестовый контур. Он универсален внутри платформы, но выгрузка занимает время и требует корректного завершения операции.

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

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

Сценарий	Основной подход	Роль DT
Файловая база	регулярная проверяемая копия	удобный перенос и контрольное восстановление
Клиент-сервер	копирование средствами СУБД по регламенту	дополнительная логическая копия
Облачная база	регламент поставщика и экспорт	если выгрузка разрешена договором

Как подготовить базу и пользователей к выгрузке

Назначьте окно работ и предупредите пользователей. Во время выгрузки не должны продолжаться ввод документов, обмены с другими базами, загрузка банковских выписок и фоновые регламентные задания. Иначе дата копии будет формально понятна, а фактическая граница данных — нет.

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

Выберите папку не внутри каталога самой файловой базы и не на единственном диске сервера. Имя файла должно читаться без открытия: организация, база, дата и время, например OOO_Ritm_BUH_2026-07-27_2300.dt. Не перезаписывайте вчерашнюю копию сегодняшней.

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

Как выгрузить информационную базу в DT

Откройте нужную информационную базу в режиме «Конфигуратор». Убедитесь, что выбрана именно рабочая база, затем используйте административную команду выгрузки информационной базы и задайте заранее подготовленный путь к файлу DT. Название пункта и доступность команды могут отличаться из-за релиза и прав.

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

Скопируйте результат во второе место хранения. Правило «рабочая база и её копия на одном диске» не защищает от отказа диска, шифровальщика или ошибки оператора. Для важной базы нужны независимые носители и ограниченный доступ.

Как восстановить DT без риска для рабочей базы

Никогда не начинайте проверку с загрузки DT поверх рабочей информационной базы. Создайте новую пустую тестовую базу с однозначным названием «ВОССТАНОВЛЕНИЕ — НЕ РАБОЧАЯ» и ограничьте доступ. Так ошибка выбора в списке баз не превратит проверку в аварию.

Откройте тестовую базу в Конфигураторе и выполните загрузку информационной базы из выбранного файла DT. Перед запуском ещё раз сравните полный путь и дату файла. После завершения перезапустите базу, если этого требует платформа.

Отключите в тестовом контуре реальные обмены, почту, рассылки, загрузку банка и другие интеграции. Восстановленная копия не должна отправить контрагенту документ, повторно загрузить операцию или записать данные во внешнюю систему. Если база участвует в синхронизации 1С:ЗУП и Бухгалтерии, обмен проверяют только на изолированных копиях обеих сторон.

Не используйте тестовую копию как параллельную рабочую базу. После проверки либо удалите её по принятому регламенту, либо оставьте как закрытый стенд с явно зафиксированной датой данных.

Что проверить после восстановления

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

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

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

Контроль	Что фиксируем	Признак успеха
Вход	роль и пользователь	сеанс открывается
Данные	последний документ и остатки	совпадают с контрольной точкой
Функции	отчёт и печатная форма	формируются без ошибки
Интеграции	список обменов	в тесте безопасно отключены

Как хранить копии и не раскрыть данные

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

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

Шифрование и пароль полезны только вместе с управлением ключами. Если пароль известен одному человеку и нигде безопасно не зафиксирован, восстановление может остановиться из-за его отсутствия. Аналогично резервная папка, постоянно подключённая с правом записи, уязвима для вредоносного ПО.

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

Как назначить периодичность и ответственного

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

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

Полезно разделить частые копии и проверку восстановления. Например, копия создаётся каждую ночь, журнал просматривается каждое утро, а отдельное восстановление проводится раз в месяц и перед крупным обновлением. Это пример, а не универсальная норма.

Зафиксируйте максимальное время возврата к работе. Тогда понятно, достаточно ли ручной загрузки DT или нужна более быстрая инфраструктурная схема.

Типичные ошибки и итоговый чек-лист

Чаще всего копия подводит не из-за формата DT, а из-за процесса: файл всегда перезаписывается, хранится рядом с базой, никогда не загружался, выгрузка запускается во время активного обмена, а ответственный узнаёт о сбое слишком поздно.

Опасна и обратная крайность: делать ручной DT единственным методом для большой клиент-серверной базы. В таком случае нужно совместно с администратором оценить резервирование СУБД, журнал транзакций, время простоя и план переключения.

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

Если все три колонки выполняются по расписанию, DT становится не случайным файлом, а проверяемой частью защиты учёта.

Вопросы и ответы

• Что находится в файле DT?

  Это логическая выгрузка структуры конфигурации и данных информационной базы 1С, предназначенная для последующей загрузки средствами платформы.

• Можно ли восстановить DT прямо в рабочую базу?

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

• Достаточно ли увидеть сообщение об успешной выгрузке?

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

• Нужно ли выгонять пользователей из 1С?

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

• Куда сохранять DT?

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

• Заменяет ли DT резервную копию СУБД?

  Для клиент-серверной базы обычно нет. DT может быть дополнительной логической копией, а основную схему проектируют с учётом конкретной СУБД и времени восстановления.

По теме