В процессе сопровождения систем на базе 1С часто возникает задача создания «песочницы» для стажеров или тестировщиков. Основная сложность заключается в том, что рабочая база обычно функционирует в клиент-серверном варианте (SQL), а тестовую копию требуется разворачивать в файловом варианте на отдельном сервере или рабочей станции. При этом процесс должен быть полностью автоматизирован, происходить в ночное время и не оставлять следов того, что база является копией (например, нужно скрыть признаки распределенной информационной базы — РИБ).
В этой статье мы подробно разберем, как реализовать такой механизм, используя стандартные возможности платформы 1С:Предприятие 8.3, пакетные файлы (BAT) и дополнительные скрипты для «заметания следов».
Для начала рассмотрим базовый механизм копирования данных. Платформа 1С поддерживает параметры запуска из командной строки, которые позволяют выполнять административные действия без участия пользователя. Основными командами для нашей задачи являются /DumpIB (выгрузка в .dt) и /RestoreIB (загрузка из .dt).
Проанализируем структуру скрипта для выгрузки базы из SQL-варианта. Нам потребуется указать адрес сервера, имя базы, а также логин и пароль пользователя с правами администратора. Создадим текстовый файл с расширением .bat и пропишем в нем следующую логику:
@echo off
set "f_name_dt=C:\Backups\WorkBase_copy.dt"
set "f_name_log=C:\Backups\log_export.txt"
set "exe1c="C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe""
echo Начало выгрузки: %date% %time% >> %f_name_log%
%exe1c% CONFIG /S "ServerName\BaseName" /N "Admin" /P "Password" /DumpIB %f_name_dt% /OUT %f_name_log% -NoTruncate
echo Завершение выгрузки: %date% %time% >> %f_name_log%
Разберем параметры подробнее: флаг CONFIG запускает конфигуратор, /S указывает путь к базе на сервере, а /OUT позволяет записывать результат выполнения операции в лог-файл. Параметр -NoTruncate важен для сохранения истории логов, чтобы файл не перезаписывался каждый раз.
После успешной выгрузки нам нужно доставить .dt файл на целевой компьютер и загрузить его в пустую (или существующую) файловую базу. Скрипт загрузки будет выглядеть так:
@echo off
set "f_name_dt=C:\Backups\WorkBase_copy.dt"
set "f_name_log=C:\Backups\log_import.txt"
set "file_base_path=D:\1C_Bases\TestBase"
set "exe1c="C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe""
echo Начало загрузки: %date% %time% >> %f_name_log%
%exe1c% CONFIG /F %file_base_path% /N "Admin" /P "Password" /RestoreIB %f_name_dt% /OUT %f_name_log% -NoTruncate
echo Завершение загрузки: %date% %time% >> %f_name_log%
Обратите внимание, что вместо параметра /S (Server) мы используем /F (File), указывая путь к папке с файловой информационной базой.
Одной из главных проблем при автоматизации является наличие активных сессий пользователей или фоновых заданий в момент начала выгрузки. Если база занята, команда /DumpIB вернет ошибку. Выясним причину, по которой обычного завершения работы недостаточно: фоновые задания 1С могут запускаться автоматически и блокировать объектный кэш или таблицы.
Для решения этой проблемы в современных версиях 8.3 рекомендуется использовать утилиту RAC и службу RAS. Это позволяет программно «выгнать» всех пользователей. Посмотрим на пример команды PowerShell, которую можно вставить в начало нашего батника:
# Завершение всех сеансов конкретной базы через RAC
& "C:\Program Files\1cv8\8.3.XX.XXXX\bin\rac.exe" session --cluster=<ID_кластера> --base=<ID_базы> terminate
Альтернативный вариант — использование V83.COMConnector для установки блокировки соединений. Это гарантирует, что пока идет процесс выгрузки, никто не сможет подключиться к базе снова.
Согласно условию, стажеры не должны видеть признаков того, что они работают в копии. Это означает, что нам нужно отключить механизмы синхронизации данных (РИБ), удалить регистрацию изменений и отключить внешние сервисы (рассылки почты, обмены с банками). Выясним, как это сделать программно.
Рассмотрим использование специальной обработки, которую мы будем запускать в тестовой базе сразу после загрузки .dt. В 1С для этого можно использовать параметр командной строки /Execute. В самой обработке в процедуре ПриОткрытии (или ПередЗаписью) пропишем следующий код:
// 1. Отключаем базу от РИБ (делаем ее автономной)
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
// 2. Удаляем регистрацию всех изменений, чтобы не копились очереди
ВыборкаУзлов = ПланыОбмена.Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
Если ВыборкаУзлов.Ссылка = ПланыОбмена.ТипВсеСсылки().ПустаяСсылка() Тогда Продолжить; КонецЕсли;
ПланыОбмена.УдалитьРегистрациюИзменений(ВыборкаУзлов.Ссылка);
КонецЦикла;
// 3. Отключаем регламентные задания, чтобы база не спамила в реальные сервисы
Задания = РегламентныеЗадания.ПолучитьРегламентныеЗадания();
Для Каждого Задание Из Задания Цикл
Задание.Использование = Ложь;
Задание.Записать();
КонецЦикла;
После выполнения этого кода база станет «чистой» и автономной. Стажеры, открыв раздел «Синхронизация данных», не увидят активных настроек обмена.
При первом запуске копии базы 1С всегда задает вопрос пользователю: «Информационная база была перемещена или восстановлена из копии?». Чтобы стажеры не видели этого окна, мы можем программно установить признак того, что база осталась прежней (с точки зрения платформы). Если ваша конфигурация использует БСП (Библиотека стандартных подсистем), проанализируем следующий метод:
// Вызывать в контексте серверного кода
ОбновлениеИнформационнойБазы.УстановитьПризнакКопииИнформационнойБазы(Ложь);
Этот вызов предотвратит блокировку работы и появление лишних диалогов. Также полезно изменить заголовок системы, чтобы администратор сам не перепутал окна. Это делается командой УстановитьЗаголовокСистемы("ТЕСТОВАЯ БАЗА (СТАЖЕРЫ)");.
Если написание скриптов кажется слишком трудоемким, разберем готовые решения, такие как «Обновлятор-1С» или «Effector Saver». Эти программы имеют встроенные планировщики и умеют:
.dt, потом загрузка в файловую базу на другом сервере.Рассмотрим пример настройки в «Обновляторе»: вы просто выбираете рабочую базу, указываете действие «Создать копию», выбираете тип «Файловая» и прописываете путь. Программа сама позаботится о блокировках и регламентных заданиях. Это решение особенно эффективно, если объем базы невелик (до 10-20 Гб), так как работа с .dt форматом на больших объемах может занимать много часов.
Посмотрим на ситуацию со стороны системных ресурсов. Выгрузка в .dt создает значительную нагрузку на процессор и дисковую подсистему сервера SQL. Если ваша база превышает 30-50 Гб, файловый вариант может работать крайне медленно из-за внутренних ограничений формата .1CD (например, лимит в 4 Гб на одну таблицу). В таких случаях мы рекомендуем рассмотреть возможность создания тестовой базы также в клиент-серверном варианте, но на бесплатной версии PostgreSQL, что позволит избежать затрат на лицензии MS SQL для тестов, сохранив высокую скорость работы.
Таким образом, мы проанализировали комплексный подход к созданию ежедневных копий: от простых пакетных файлов до интеллектуальной очистки данных. Следуя этим шагам, вы обеспечите стабильную среду для обучения персонала, не подвергая риску рабочие данные.