Резервная копия 1С: как сделать и не потерять данные

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

Способ создания копии зависит от режима работы базы. Файловая база (один файл 1Cv8.1CD) копируется проще всего, но требует выхода всех пользователей. Клиент-серверный вариант на MS SQL Server, PostgreSQL или Oracle копируется средствами СУБД, а выгрузка через конфигуратор в этом случае служит дополнительным, а не основным инструментом.

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

Определите, какой у вас тип базы

Перед настройкой копирования нужно понять, в каком режиме работает информационная база. Откройте список баз в окне запуска 1С, выделите нужную базу и посмотрите строку подключения внизу окна или нажмите «Изменить».

Если путь выглядит как папка на диске или сетевом ресурсе (например, D:\Bases\Trade или \\Server\Bases\Trade) — это файловый вариант. Вся база хранится в одном файле 1Cv8.1CD внутри этой папки, и основные способы копирования — выгрузка в dt или копирование файла при остановленной работе.

Если указан сервер 1С:Предприятия и имя базы — это клиент-серверный вариант. Данные лежат в СУБД, и простое копирование файлов здесь не работает: нужны штатные средства резервного копирования SQL-сервера.

Сделайте копию файловой базы через выгрузку в dt

Выгрузка в dt — универсальный и самый надёжный способ для файловой базы. Конфигуратор формирует согласованный снимок базы, который легко перенести и восстановить. Единственное условие — во время выгрузки пользователи не должны работать в базе, иначе выгрузка завершится с ошибкой или данные будут несогласованными.

1. 1
   Попросите всех пользователей выйти из базы и проверьте активные сеансы
2. 2
   Откройте базу в режиме Конфигуратор под учётной записью с полными правами
3. 3
   Выберите меню Администрирование → Выгрузить информационную базу
4. 4
   Укажите папку и имя файла, например trade_2026-06-01.dt
5. 5
   Дождитесь окончания выгрузки и проверьте, что файл создан и имеет ненулевой размер
6. 6
   Скопируйте файл dt на отдельный носитель или сетевое хранилище

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

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

Скопируйте файловую базу на уровне файлов

Второй способ для файлового варианта — скопировать сам файл 1Cv8.1CD вместе с папкой базы. Такой способ быстрее выгрузки в dt для больших баз и не требует запуска конфигуратора, но у него есть жёсткое ограничение: копировать файл можно только когда с базой никто не работает.

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

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

robocopy "D:\Bases\Trade" "E:\Backup\Trade_%date:~6,4%-%date:~3,2%-%date:~0,2%" 1Cv8.1CD

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

В клиент-серверном варианте данные хранятся в СУБД, поэтому резервное копирование выполняется её штатными средствами. Для MS SQL Server это планы обслуживания или задания агента SQL Server с операцией Backup Database; для PostgreSQL — утилита pg_dump или физическое копирование с WAL-архивом.

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

Выгрузка в dt для клиент-серверной базы тоже возможна и полезна как дополнительный уровень защиты: dt-файл независим от СУБД и позволяет поднять базу даже при полной потере сервера. Однако делать dt основным способом для большой клиент-серверной базы не стоит — выгрузка занимает много времени и требует монопольного доступа.

Организуйте расписание и место хранения

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

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

Автоматизируйте процесс: для dt-выгрузки используйте запуск конфигуратора из командной строки с параметрами /DumpIB, для SQL — встроенные задания агента. После каждого автоматического копирования проверяйте результат: наличие файла, его размер и отсутствие ошибок в журнале задания.

Проверьте, что копия восстанавливается

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

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

Учтите ограничения и частые ошибки

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

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

Отдельно стоит сказать про «теневые копии» Windows и снапшоты виртуальных машин: это полезное дополнение, но не замена штатному копированию. Снапшот фиксирует состояние диска, которое может оказаться несогласованным на уровне данных, если копирование застало активную запись.

Частые вопросы о резервном копировании 1С