Как настроить автоматическое резервное копирование 1С 8.3

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

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

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

Что нужно определить до настройки

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

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

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

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

Выгрузка в DT через конфигуратор — универсальный метод: полученный файл можно загрузить в базу на другой платформе или другой СУБД. Минусы — требуется монопольный доступ (все пользователи должны выйти), а на больших базах процесс длителен.

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

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

Настройка автоматической выгрузки DT для файловой базы

Основа автоматизации — пакетный режим конфигуратора. Создайте командный файл (например, backup.cmd) с командой запуска 1cv8.exe с параметром DUMPIB, указанием строки подключения к базе, пользователя с правами администратора и пути к файлу выгрузки.

В имени файла копии используйте дату и время, чтобы копии не перезаписывали друг друга. В cmd это можно сделать подстановкой переменных %DATE% и %TIME% с заменой недопустимых символов, либо через PowerShell, где форматирование даты проще.

Затем создайте задание в планировщике задач Windows: триггер — ежедневно в нерабочее время (например, ночью), действие — запуск вашего cmd-файла, запуск от имени учётной записи с правами доступа к базе и к каталогу копий. Включите опцию «Выполнять вне зависимости от регистрации пользователя».

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /NАдминистратор /PПароль /DumpIB"E:\Backup\trade_%DATE:~6,4%%DATE:~3,2%%DATE:~0,2%.dt" /DisableStartupDialogs

1. 1
   Создайте отдельный каталог для копий на другом диске или сетевом ресурсе
2. 2
   Напишите cmd-файл с командой конфигуратора DUMPIB и динамическим именем файла
3. 3
   Запустите файл вручную и убедитесь, что DT создаётся без ошибок
4. 4
   Создайте задание в планировщике задач Windows на ночное время
5. 5
   Через сутки проверьте, что копия появилась, и выполните тестовую загрузку в пустую базу

Настройка бэкапа для клиент-серверной базы

В MS SQL Server используйте план обслуживания (Maintenance Plan) или задание SQL Server Agent с командой BACKUP DATABASE. Настройте полную копию ежедневно и, при необходимости, разностные копии в течение дня. Храните файлы .bak на отдельном физическом носителе.

Для PostgreSQL применяйте pg_dump или pg_basebackup по расписанию через планировщик ОС. Учитывайте, что пользователь, от имени которого выполняется выгрузка, должен иметь достаточные права в СУБД.

Важно: бэкап СУБД фиксирует данные на уровне базы, но не включает настройки кластера 1С и список баз. Зафиксируйте отдельно параметры регистрации базы в консоли кластера — это ускорит восстановление на новом сервере.

Где хранить копии и сколько их держать

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

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

Автоматизируйте и очистку: добавьте в скрипт удаление файлов старше заданного срока (в PowerShell — через Get-ChildItem с фильтром по дате), иначе диск под копии рано или поздно переполнится, и новые копии перестанут создаваться.

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

Признак рабочей системы резервного копирования — не наличие файлов, а успешное восстановление. Раз в месяц загружайте свежую копию в тестовую базу: для DT — через «Загрузить информационную базу» в конфигураторе, для SQL — через RESTORE DATABASE в копию с другим именем.

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

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

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

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

Вторая ошибка — хранение копий до переполнения диска. Третья — отсутствие проверки восстановления: выгрузка может завершаться «успешно», но файл окажется нечитаемым из-за нехватки места в момент записи.

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

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