Администрирование · 10 мин
Как настроить автоматический бэкап базы данных 1С
Как настроить автоматический бэкап базы 1С: выгрузка dt, средства СУБД, планировщик заданий, проверка копий и типичные ошибки администраторов.
Регулярная резервная копия — единственная надёжная защита от потери учётных данных при сбое диска, повреждении базы или ошибочных действиях пользователя. Автоматический бэкап снимает с администратора необходимость помнить о ручных выгрузках и гарантирует, что копия создаётся по расписанию даже в выходные и праздники.
Способ настройки зависит от режима работы базы. Файловая база копируется либо выгружается в файл .dt штатными средствами конфигуратора, а клиент-серверная база на MS SQL Server или PostgreSQL резервируется средствами самой СУБД — это быстрее и не требует остановки работы пользователей.
Ниже разобраны оба сценария: от встроенного механизма резервного копирования в типовых конфигурациях до скриптов для планировщика заданий Windows и планов обслуживания SQL Server. Отдельно описаны проверка копий, хранение и типичные ошибки, из-за которых бэкап формально есть, а восстановиться из него нельзя.
Выберите способ резервного копирования под свой режим работы
Прежде чем настраивать расписание, определите, как развёрнута база. От этого зависит инструмент: метод, идеальный для файловой базы, для SQL-версии неудобен и медленен.
Файловая база — это каталог с файлом 1Cv8.1CD. Клиент-серверная база хранится в СУБД, а сервер 1С лишь обеспечивает доступ. Смешивать подходы нельзя: простое копирование файлов базы данных SQL Server при работающей службе даёт повреждённую копию.
Сравнение способов бэкапа
Подходит для файловых баз и переноса между платформами. Требует монопольного доступа, на больших базах выполняется долго.
Быстро и просто, но только при гарантированном отсутствии активных сеансов, иначе копия может быть несогласованной.
Оптимально для клиент-серверных баз: работает без остановки пользователей, поддерживает разностные копии и журналы транзакций.
Простая настройка из интерфейса 1С, но копия создаётся только пока запущен сеанс пользователя с соответствующими правами.
Настройте встроенное резервное копирование в типовой конфигурации
В типовых конфигурациях на Библиотеке стандартных подсистем (БСП) — «1С:Бухгалтерия», «1С:Зарплата и управление персоналом», «1С:Управление нашей фирмой» и других — есть готовый механизм резервного копирования. Он находится в разделе администрирования: «Администрирование» → «Обслуживание» → «Резервное копирование и восстановление» (в некоторых конфигурациях путь называется «Резервное копирование ИБ»).
В настройках укажите каталог для хранения копий и расписание: при завершении работы программы или по расписанию (ежедневно, еженедельно в заданное время). Механизм создаёт выгрузку .dt в указанную папку и может вести архив нескольких последних копий.
Важное ограничение: копирование выполняется только когда запущен сеанс пользователя, которому назначена настройка. Если все вышли из программы до наступления времени бэкапа — копия не создастся. Поэтому этот способ подходит как дополнительный уровень защиты, но не как единственный.
Автоматизируйте выгрузку .dt через пакетный режим конфигуратора
Универсальный способ для файловых баз без привязки к сеансу пользователя — запуск конфигуратора в пакетном режиме с командой DumpIB. Создайте командный файл backup.cmd примерно такого содержания:
"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /N"Администратор" /P"пароль" /DumpIB"E:\Backups\Trade_%date:~6,4%-%date:~3,2%-%date:~0,2%.dt" /DisableStartupDialogsЗдесь /F указывает путь к файловой базе, /N и /P — имя и пароль пользователя с правами администратора, /DumpIB — путь к создаваемому файлу выгрузки. Дата в имени файла позволяет хранить историю копий и не перезаписывать предыдущие.
Выгрузка .dt требует монопольного доступа: если в базе работают пользователи, команда завершится ошибкой. Поэтому планируйте задание на ночь и перед выгрузкой завершайте сеансы либо принимайте риск пропуска копии. Для клиент-серверной базы вместо /F используется /S с указанием сервера и имени базы.
Настройте задание в планировщике Windows
Планировщик заданий Windows превращает командный файл в полноценный автоматический бэкап. Откройте «Планировщик заданий» (taskschd.msc), создайте новую задачу и задайте параметры.
- 1Откройте taskschd.msc и выберите «Создать задачу» (не «простую задачу» — так больше настроек).
- 2На вкладке «Общие» задайте имя, включите «Выполнять вне зависимости от регистрации пользователя» и «Выполнять с наивысшими правами».
- 3На вкладке «Триггеры» добавьте расписание: ежедневно в нерабочее время, например в 02:00.
- 4На вкладке «Действия» укажите запуск вашего backup.cmd.
- 5На вкладке «Параметры» включите перезапуск при сбое и снимите ограничение времени выполнения для больших баз.
- 6Сохраните задачу, введите учётные данные и выполните тестовый запуск кнопкой «Выполнить».
Учётная запись, от имени которой выполняется задача, должна иметь доступ на чтение к каталогу базы и на запись в каталог бэкапов, включая сетевые пути. Если копии сохраняются на сетевой диск, используйте UNC-пути (\\server\share), а не подключённые буквы дисков — при выполнении без регистрации пользователя сетевые диски не подключаются.
После настройки проверьте журнал планировщика: код завершения 0 означает успех. Любой другой код — повод открыть командный файл вручную и посмотреть текст ошибки.
Настройте бэкап клиент-серверной базы средствами СУБД
Для баз на MS SQL Server штатный инструмент — план обслуживания (Maintenance Plan) в SQL Server Management Studio. Создайте план с задачей «Back Up Database», выберите тип Full (полная копия), укажите базу и каталог назначения, задайте расписание — например, полная копия ежедневно ночью.
Если база работает в полной модели восстановления (Full recovery model), добавьте регулярный бэкап журнала транзакций — например, каждый час. Это позволит восстановить базу на произвольный момент времени, а не только на момент ночной копии. Следите, чтобы журнал не разрастался: без регулярных бэкапов журнала файл .ldf может занять всё место на диске.
Для PostgreSQL используется утилита pg_dump, запускаемая по расписанию через планировщик Windows или cron на Linux. Команда вида pg_dump -U postgres -Fc dbname > backup.dump создаёт сжатую копию, которую затем восстанавливают через pg_restore.
Бэкап средствами СУБД не заменяет выгрузку .dt полностью: перед обновлением конфигурации или переносом базы между разными СУБД всё равно делайте выгрузку через конфигуратор — .dt независим от версии и типа СУБД.
Организуйте хранение копий и ротацию
Копия, лежащая на том же диске, что и база, не защищает ни от отказа диска, ни от шифровальщика. Минимальное требование — отдельный физический носитель: второй сервер, NAS или внешний диск. Оптимально — дополнительная копия в другом помещении или в облачном хранилище.
Настройте ротацию, чтобы архив не заполнил диск. Простая схема: ежедневные копии за последнюю неделю, еженедельные — за месяц, ежемесячные — за год. Ротацию реализуют либо скриптом, удаляющим файлы старше заданного срока, либо средствами самого ПО резервного копирования.
Следите за свободным местом в каталоге бэкапов. Переполненный диск — самая частая причина молчаливого прекращения резервного копирования: задание завершается ошибкой, а администратор узнаёт об этом только когда копия понадобилась.
Проверяйте копии и контролируйте выполнение заданий
Бэкап считается настроенным только после проверки восстановления. Для файловой базы периодически загружайте свежий .dt в тестовую базу через конфигуратор (LoadIB) и убеждайтесь, что база открывается и данные на месте. Для SQL-бэкапа выполняйте тестовое восстановление в базу с другим именем.
Настройте контроль самого факта выполнения: проверяйте код возврата задания планировщика, наличие свежего файла в каталоге копий и его размер. Резкое уменьшение размера копии по сравнению с предыдущими — тревожный признак: возможно, выгрузка оборвалась.
Как проверить результат
Свежий файл с ожидаемой датой и характерным размером в каталоге бэкапов
Файл отсутствует или его дата старше одного-двух дней
0x0 — успешное завершение
Любой другой код — смотреть журнал и текст ошибки
База загружается из копии и открывается, данные актуальны
Ошибка загрузки .dt или восстановления из SQL-бэкапа
Сопоставим с предыдущими копиями, плавно растёт
Резко меньше обычного — вероятна неполная выгрузка
Частые вопросы по автоматическому бэкапу 1С
Можно ли делать бэкап файловой базы, пока в ней работают пользователи?
Выгрузка .dt через конфигуратор требует монопольного доступа и при активных сеансах завершится ошибкой. Копирование файла 1Cv8.1CD во время работы технически возможно, но копия может оказаться несогласованной. Планируйте бэкап на нерабочее время или заранее завершайте сеансы.
Чем выгрузка .dt отличается от копирования файла базы?
Файл .dt — это логическая выгрузка данных и конфигурации, независимая от версии платформы и пригодная для переноса между файловым и клиент-серверным режимами. Копирование 1Cv8.1CD быстрее, но привязано к файловому формату и требует отсутствия активных сеансов.
Как часто нужно делать резервные копии?
Минимум — ежедневно для активно используемой базы. Если потеря данных за несколько часов критична, в клиент-серверном варианте добавьте бэкап журнала транзакций каждый час — это позволит восстановить базу почти на момент сбоя.
Почему задание планировщика выполняется, а файл бэкапа не появляется?
Чаще всего причины в правах доступа учётной записи задания к сетевому каталогу, использовании подключённых сетевых дисков вместо UNC-путей или ошибке внутри скрипта. Проверьте код завершения задания и запустите командный файл вручную, чтобы увидеть текст ошибки.
Нужно ли делать бэкап перед обновлением конфигурации?
Да, обязательно. Перед обновлением сделайте выгрузку .dt, даже если настроен регулярный бэкап средствами СУБД: .dt позволяет откатиться независимо от типа базы и состояния SQL-копий. Платформа при обновлении сама предлагает создать резервную копию — не отказывайтесь.
Сколько копий стоит хранить?
Ориентируйтесь на схему с ротацией: ежедневные копии за неделю, еженедельные за месяц, ежемесячные за год. Глубина архива ограничена только объёмом хранилища, но минимум три-четыре свежие копии должны быть всегда — на случай, если повреждение данных обнаружится не сразу.
Что важно запомнить
Способ автоматического бэкапа выбирается по режиму базы: файловая — выгрузка .dt через пакетный режим конфигуратора и планировщик Windows, клиент-серверная — план обслуживания СУБД. Копии хранятся на отдельном носителе с ротацией, а регулярное тестовое восстановление подтверждает, что бэкап реально работает.