Бэкап 1С: как лучше организовать резервное копирование

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

Универсального «лучшего» способа нет: выбор зависит от режима работы базы (файловый или клиент-серверный), объёма данных, допустимого простоя и того, сколько времени работы вы готовы потерять при сбое. Ниже разберём основные методы резервного копирования 1С, их ограничения, порядок настройки и способы проверить, что копия действительно восстанавливается.

Что именно нужно копировать в 1С

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

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

Способы резервного копирования: сравнение и выбор

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

Бэкап файловой базы: порядок настройки

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

Типовая команда пакетной выгрузки выглядит так:

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

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

Бэкап клиент-серверной базы через СУБД

В клиент-серверном режиме правильный путь — штатные механизмы резервного копирования СУБД. Для MS SQL Server это планы обслуживания (Maintenance Plans) или скрипты BACKUP DATABASE с полной копией раз в день и разностными (differential) или копиями журнала транзакций в течение дня. Для PostgreSQL — pg_dump или физическое копирование с WAL-архивом. Такой подход не требует остановки работы пользователей и позволяет восстановить базу на конкретный момент времени.

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

1. 1
   Определите допустимую потерю данных (RPO): час, день — от этого зависит частота копий
2. 2
   Настройте полную копию ежедневно в нерабочее время
3. 3
   Добавьте разностные копии или копии журнала транзакций каждые 1–4 часа
4. 4
   Настройте копирование файлов бэкапа на другое устройство или в облачное хранилище
5. 5
   Раз в месяц выполняйте тестовое восстановление на отдельном сервере

Правило 3-2-1 и где хранить копии

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

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

Проверка восстановления и типичные ошибки

Бэкап существует только тогда, когда из него восстановили базу и проверили данные. Минимальный контроль: раз в месяц загрузить свежий .dt в тестовую базу или восстановить SQL-копию на тестовом сервере, открыть базу, сверить обороты за последний закрытый период и количество документов. Для .dt дополнительный признак целостности — успешная загрузка без ошибок; для SQL — успешное выполнение RESTORE VERIFYONLY и тестового восстановления.

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