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

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

Способ настройки зависит от того, как развёрнута ваша база. Для файловой базы достаточно пакетной выгрузки в файл .dt через конфигуратор и планировщика заданий Windows. Для клиент-серверного варианта на MS SQL Server или PostgreSQL правильнее делать копии средствами самой СУБД, а выгрузку .dt использовать как дополнительный контур защиты.

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

Определяем тип базы: файловая или клиент-серверная

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

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

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

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

"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

Параметр /F указывает путь к базе, /N и /P — логин и пароль пользователя с правами администратора, /DumpIB — путь и имя файла выгрузки. Включение даты в имя файла позволяет хранить несколько копий и не затирать предыдущие. Учтите, что путь к 1cv8.exe зависит от версии платформы — проверьте актуальный каталог на своём компьютере.

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

Ставим задачу в планировщик Windows

Планировщик заданий Windows — встроенный инструмент, который запускает ваш bat-файл по расписанию без сторонних программ. Откройте «Планировщик заданий» (команда taskschd.msc), создайте новую задачу, укажите триггер — ежедневно в ночное время, действие — запуск вашего bat-файла.

1. 1
   Создайте bat-файл с командой выгрузки и проверьте его запуск вручную
2. 2
   Откройте планировщик заданий (taskschd.msc) и выберите «Создать задачу»
3. 3
   На вкладке «Общие» отметьте «Выполнять вне зависимости от регистрации пользователя» и «Выполнять с наивысшими правами»
4. 4
   На вкладке «Триггеры» задайте ежедневный запуск в нерабочее время, например в 2:00
5. 5
   На вкладке «Действия» укажите запуск bat-файла и пропишите рабочую папку
6. 6
   Сохраните задачу, введите пароль учётной записи и выполните пробный запуск кнопкой «Выполнить»
7. 7
   Проверьте, что файл .dt появился в целевой папке и имеет ненулевой размер

Обратите внимание на учётную запись, от имени которой выполняется задача. У неё должны быть права на чтение каталога базы и запись в папку с копиями, включая сетевые пути, если копии складываются на другой сервер. Частая причина «молчаливых» сбоев — задача запускается, но не имеет доступа к сетевому ресурсу, и копия просто не создаётся.

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

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

Для базы на MS SQL Server стандартный подход — план обслуживания (Maintenance Plan) в SQL Server Management Studio. Настройте полную копию (Full) ежедневно, разностную (Differential) несколько раз в день и копии журнала транзакций (Log) каждые 15–60 минут, если база в полной модели восстановления. Такая схема позволяет восстановить данные на любой момент времени, а не только на момент ночной копии.

Для PostgreSQL используйте pg_dump по расписанию через планировщик или cron, либо физическое копирование с архивацией WAL. Логическая выгрузка pg_dump проще в настройке и переносе между версиями, физические копии быстрее восстанавливаются на больших базах.

Даже при настроенных бэкапах СУБД выгрузка .dt остаётся полезной: это единственный формат, который гарантированно открывается конфигуратором независимо от версии и состояния SQL-сервера. Многие администраторы делают .dt раз в неделю как «холодный» резерв.

Куда складывать копии и сколько их хранить

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

Глубину хранения выбирайте исходя из объёма данных и требований учёта. Рабочая практика — ежедневные копии за последние 1–2 недели, еженедельные за 1–2 месяца, ежемесячные за год. Это защищает не только от поломок, но и от «тихих» ошибок: если данные испортили неделю назад, а заметили только сейчас, понадобится старая копия.

Автоматизируйте удаление устаревших копий, иначе диск рано или поздно переполнится, и новые копии перестанут создаваться. Для этого добавьте в bat-файл команду удаления файлов старше заданного срока, например через forfiles, или используйте настройки очистки в плане обслуживания SQL Server.

Проверяем, что копии реально восстанавливаются

Резервная копия, которую ни разу не пробовали восстановить, — это предположение, а не защита. Выделите тестовый каталог или тестовый сервер и раз в месяц восстанавливайте свежую копию: загружайте .dt в пустую базу через конфигуратор (Загрузить информационную базу) или восстанавливайте бэкап в тестовую базу SQL Server.

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

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

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

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