Как делать резервную копию 1С: полное руководство

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

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

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

Как определить режим работы вашей базы

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

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

Выгрузка базы через конфигуратор

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

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

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

Копирование файловой базы напрямую

Если база файловая, допустим более простой путь: скопировать файл 1Cv8.1CD из папки базы. Это быстрее выгрузки и не требует запуска конфигуратора, что удобно для автоматизации обычным скриптом или планировщиком задач Windows.

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

Копировать нужно именно файл 1Cv8.1CD — в нём вся база. Служебные файлы журналов и индексов для резервной копии не обязательны. После копирования полезно открыть копию в тестовом режиме и убедиться, что база запускается и данные на месте.

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

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

BACKUP DATABASE [TradeBase] TO DISK = 'D:\Backups\TradeBase_full.bak' WITH COMPRESSION, CHECKSUM;

Для MS SQL Server рекомендуется полная модель восстановления с регулярными копиями журнала транзакций — это позволяет восстановить базу на произвольный момент времени, а не только на момент последнего полного бэкапа. Для небольших баз достаточно простой модели с ежедневной полной копией.

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

Как организовать регулярное копирование и хранение

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

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

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

Проверка и восстановление копии

Резервная копия считается существующей только после успешной проверки восстановления. Для файла .dt создайте пустую тестовую базу и выполните «Администрирование → Загрузить информационную базу». Для скопированного 1Cv8.1CD добавьте папку с копией в список баз и откройте её. Для SQL-бэкапа восстановите базу под тестовым именем на том же или отдельном сервере.

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

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