Резервная копия 1С 8.3: как настроить копирование в облако

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

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

Какие способы облачного резервного копирования существуют

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

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

Подготовка: выгрузка базы в файл dt

Файл выгрузки (расширение dt) создаётся через конфигуратор: меню «Администрирование» → «Выгрузить информационную базу». Для автоматизации используется пакетный режим запуска конфигуратора с параметром DumpIB. Выгрузка требует монопольного доступа — все сеансы пользователей должны быть завершены.

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /N"Администратор" /P"пароль" /DumpIB"D:\Backup\trade_%date%.dt" /DisableStartupDialogs

Обратите внимание на путь к исполняемому файлу: номер версии платформы в пути меняется после обновлений, и скрипт с жёстко прописанной версией перестаёт работать. Надёжнее вызывать ярлык 1cestart.exe или обновлять путь в скрипте при каждом обновлении платформы.

Не путайте выгрузку в dt с простым копированием файла 1Cv8.1CD. Копирование файловой базы допустимо только при гарантированном отсутствии открытых сеансов, иначе копия окажется повреждённой. Выгрузка через конфигуратор дополнительно проверяет структуру базы и чаще выявляет скрытые ошибки.

Автоматизация по расписанию

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

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

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

Перед началом выгрузки полезно программно завершать сеансы пользователей и блокировать новые соединения, иначе задание будет регулярно завершаться ошибкой монопольного доступа. В клиент-серверном варианте это делается через консоль кластера или утилиту администрирования rac.

Выбор облачного хранилища и передача файлов

Практически любое хранилище подходит, если есть способ автоматической загрузки: Яндекс Диск, Google Drive, OneDrive, Dropbox, а также S3-совместимые объектные хранилища (например, облачные сервисы российских провайдеров). Критерии выбора: объём базы, стоимость хранения, скорость загрузки и наличие API или утилиты командной строки.

Два рабочих подхода к передаче:

• Клиент синхронизации. Папка резервных копий добавляется в синхронизируемую папку облачного клиента. Плюс — нулевая настройка; минус — при шифровальщике повреждённые файлы тут же синхронизируются в облако, заменяя исправные копии (частично сглаживается версионированием на стороне сервиса).
• Утилита командной строки (rclone, REST API). Скрипт после выгрузки явно копирует файл в облако. Гибче: можно задавать ротацию, шифрование и целевые каталоги, не синхронизируя лишнего.

rclone copy D:\Backup remote:1c-backup --max-age 1d --log-file D:\Backup\rclone.log

Учитывайте объём: dt-файл базы в несколько гигабайт при медленном канале будет загружаться часами. Проверьте фактическую скорость отдачи интернет-канала и заложите это время в ночное окно. Некоторые хранилища ограничивают максимальный размер одного файла — уточните лимит до настройки.

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

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

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

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

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

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

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

Часто задаваемые вопросы