Как настроить периодическую актуализацию данных в копии базы 1С с MS SQL

При обслуживании и разработке крупных систем, таких как 1С:ERP Управление предприятием, часто возникает необходимость иметь актуальные данные из рабочей (боевой) базы в копии. Актуальные данные нужны для поиска причин ошибок, проверки алгоритмов и отладки сложных отчетов без риска испортить рабочую информационную базу.

Однако регулярный перенос данных «накатыванием» полного бэкапа поверх базы разработки создает трудности: сбрасывается связь с хранилищем конфигурации, восстанавливаются включенные регламентные задания, а также возникает риск случайной отправки сообщений во внешние сервисы. Разберем по шагам, как правильно построить архитектуру тестового контура и автоматизировать обновление данных.

Оптимальная архитектура: Разделение среды разработки и тестовой базы

Главная ошибка при организации работы — использование одной и той же копии базы и для разработки новой функциональности (с подключением к хранилищу конфигурации), и для поиска ошибок на свежих продуктивных данных.

Разберем наиболее эффективную схему разделения контуров:

1. База разработки (Dev): Находится на отдельном сервере или отдельном кластере 1С, подключена к хранилищу конфигурации (или системе контроля версий). В этой базе актуальность оперативных данных не имеет первостепенного значения. Обновление структуры метаданных из рабочей базы или хранилища выполняется планово (например, раз в месяц или в конце спринта).
2. Тестовая база / База поддержки (Test/Support): Не подключена к хранилищу конфигурации. Служит исключительно для моделирования рабочих ситуаций, отладки и проверки обработок на актуальных данных. Данная база регулярно (еженощно или раз в неделю) автоматически перезаписывается свежим бэкапом рабочей базы средствами MS SQL.

Автоматизация разворачивания копии на уровне MS SQL

Для автоматической перезаписи тестовой базы свежими данными рабочей базы по расписанию используется следующий алгоритм на стороне СУБД MS SQL Server:

1. Перевод целевой тестовой базы в монопольный режим для завершения всех активных сеансов: ALTER DATABASE [Test_ERP] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
2. Восстановление базы данных из актуального бэкапа продуктивной базы с заменой существующей базы и перемещением файлов:
   Скопировать код

   
   RESTORE DATABASE [Test_ERP] 
   FROM DISK = 'D:\Backups\ERP_prod_fresh.bak' 
   WITH REPLACE, 
   MOVE 'ERP_prod_Data' TO 'D:\SQLData\Test_ERP.mdf',
   MOVE 'ERP_prod_Log' TO 'L:\SQLLogs\Test_ERP_log.ldf';
   

3. Возврат базы данных в многопользовательский режим работы: ALTER DATABASE [Test_ERP] SET MULTI_USER;

Выполнение этого T-SQL скрипта можно настроить через SQL Server Agent или с помощью командлетов PowerShell в планировщике задач Windows на ночное время.

Безопасность и отключение регламентных заданий

Чтобы развернутая копия базы не начала выполнять регламентные задания, отправлять клиентам почтовые рассылки или синхронизироваться с внешними системами (ЭДО, маркетплейсы, банк-клиент), необходимо соблюдать правила предосторожности:

1. Блокировка на уровне кластера 1С: На сервере 1С:Предприятия в свойствах тестовой информационной базы всегда должен быть установлен флаг «Блокировка регламентных заданий включена».
2. Использование отдельной службы сервера 1С: Для среды разработки и тестирования рекомендуется создавать отдельный рабочий процесс 1С на невложенном порту, чтобы исключить случайный запуск на продакшн-кластере.

Создать отдельную службу сервера 1С для тестового контура можно через командную строку Windows:

sc create "ragent-dev@1641" binPath= "\"C:\Program Files\1cv8\8.3.23.1865\bin\ragent.exe\" /srvc /agent /regport 1640 /port 1641 /range 1660:1690 /d \"D:\1C\ragent-dev-data\" /debug" start= auto obj=USR1CV8 password=password displayname="Сервер 1С:Предприятия (Разработка)" depend= Dnscache/Tcpip/lanmanworkstation/lanmanserver

При первом запуске восстановленной копии конфигурации на базе Библиотеки Стандартных Подсистем (БСП) сработает встроенный механизм защиты: система определит изменение параметров размещения базы и предложит заблокировать внешние ресурсы и работу с интеграциями.

Перенос изменений из базы разработки в тестовую базу

Когда обработка или исправление ошибки разработаны в базе Dev, для их проверки на актуальных данных тестовой базы Test_ERP применяется автоматическая загрузка конфигурации или расширения. Для этого используется запуск Конфигуратора в командном режиме:

"C:\Program Files\1cv8\8.3.23.1865\bin\1cv8.exe" DESIGNER /S "test-server\Test_ERP" /N "Administrator" /P "password" /LoadCfg "D:\Releases\latest_changes.cf" /UpdateDBCfg

Использование двухбазовой схемы (отдельно Dev для написания кода с хранилищем, отдельно Test для ночной перезаливки бэкапа MS SQL) позволяет сохранить стабильность среды разработки и всегда иметь под рукой актуальные данные для отладки.