Как резервировать в 1С: способы, инструкции и контроль копий

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

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

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

Какие способы резервирования существуют в 1С

В практике применяются четыре подхода. Первый — выгрузка информационной базы в файл .dt через конфигуратор: создаётся переносимый архив, который можно загрузить в пустую базу на любом компьютере. Второй — копирование файла 1Cv8.1CD файловой базы средствами операционной системы. Третий — штатный бэкап средствами СУБД для клиент-серверных баз. Четвёртый — механизм резервного копирования, встроенный в некоторые типовые конфигурации («Администрирование» → «Резервное копирование и восстановление»).

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

Выгрузка базы в файл .dt через конфигуратор

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

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

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

Восстановление выполняется обратной операцией: создаётся пустая база, в конфигураторе выбирается «Администрирование» → «Загрузить информационную базу», указывается файл .dt. После загрузки обязательно проверьте, что открываются отчёты и документы за последние периоды.

Резервное копирование файловой базы

Файловая база — это каталог, в котором основной объём занимает файл 1Cv8.1CD. Самый простой способ резервирования — скопировать весь каталог базы в другое место, когда в ней никто не работает. Открытые сеансы держат файл заблокированным, и копия, снятая «на живую» простым копированием, может оказаться повреждённой.

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

robocopy "D:\Bases\Trade" "\\NAS\Backup\Trade_%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2%" /E /R:2 /W:5 /LOG+:C:\Scripts\backup.log

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

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

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

MS SQL Server

В SQL Server Management Studio создаётся план обслуживания с задачей полного резервного копирования (Full Backup) базы. Для баз с интенсивной работой дополнительно настраивают разностные копии и копии журнала транзакций — это позволяет восстановить состояние на конкретный момент времени. Модель восстановления базы при этом должна быть Full, а не Simple.

PostgreSQL

Для PostgreSQL применяется утилита pg_dump (логическая копия) или pg_basebackup с архивированием WAL для крупных баз. Логическая копия удобна для переноса, физическая — для быстрого восстановления больших объёмов.

pg_dump -U postgres -F c -f /backup/ut_base_$(date +%F).dump ut_base

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

Как организовать расписание и хранение копий

Копия, которую делают «когда вспомнят», не защищает. Настройте автоматическое выполнение: планировщик заданий Windows для файловых баз и скриптов, планы обслуживания или cron для СУБД. Частота зависит от интенсивности работы: при ежедневном вводе документов копия нужна минимум раз в день.

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

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

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

Главный критерий работающей системы резервирования — успешное восстановление, а не наличие файлов копий. Раз в месяц или хотя бы раз в квартал поднимайте копию на тестовой базе: загрузите .dt в пустую базу или восстановите бэкап СУБД под другим именем.

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

Типичные ошибки и ограничения

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

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