Что такое бэкап базы данных 1С и как его правильно делать

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

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

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

Что именно входит в бэкап базы 1С

Информационная база 1С хранит в одном хранилище и прикладные данные (документы, справочники, регистры, проводки), и метаданные конфигурации — описание объектов, модулей, форм. Полноценный бэкап охватывает оба слоя, поэтому из него можно поднять базу «как есть» на другом компьютере или сервере.

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

Основные виды бэкапов и когда какой применять

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

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

Как сделать бэкап файловой базы

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

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

Альтернатива — копирование каталога базы целиком. Такая копия восстанавливается мгновенно: достаточно вернуть каталог на место и подключить базу. Критическое условие — на момент копирования с базой никто не должен работать, иначе файл 1Cv8.1CD может быть скопирован в несогласованном состоянии, и копия окажется битой. Безопасный вариант — копировать ночью по расписанию с предварительной блокировкой сеансов.

Как организовать бэкап клиент-серверной базы

Для баз на MS SQL Server, PostgreSQL или другой поддерживаемой СУБД резервное копирование настраивается штатными средствами самой СУБД. Такой бэкап создаётся «на горячую», без выгона пользователей, и при правильной модели восстановления позволяет откатить базу на произвольный момент времени, а не только на момент последней полной копии.

Типовая схема для рабочей базы: полная копия ежедневно в нерабочее время, разностные копии несколько раз в день, копии журнала транзакций — с интервалом, который определяет допустимую потерю данных (например, каждые 15–30 минут). Конкретные интервалы выбираются исходя из интенсивности работы и требований бизнеса к точке восстановления.

BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backups\MyBase1C_full.bak' WITH COMPRESSION, CHECKSUM

Обратите внимание: бэкап средствами СУБД восстанавливается тоже средствами СУБД, а не через конфигуратор. После восстановления базу нужно зарегистрировать в кластере 1С (или переподключить существующую регистрацию к восстановленной базе). Этот момент часто упускают при первой самостоятельной настройке.

Расписание, хранение и правило нескольких копий

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

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

Как проверить, что бэкап рабочий

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

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

Типичные ошибки и частые вопросы

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