← На главную

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

Как работает механизм определения перемещения базы

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

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

Основные причины ложного срабатывания

Проанализируем распространенные сценарии, когда база фактически остается на месте, но система фиксирует факт «перемещения»:

1. Разночтения в строке подключения у разных пользователей:

   Если один системный администратор заходит в базу по сетевому имени сервера (server1c), а другие пользователи — по IP-адресу (192.168.1.100) или полному доменному имени FQDN (server1c.domain.local), платформа видит разные строки соединения. При сохранении новых параметров одним пользователем у всех остальных при следующем входе появится запрос о перемещении базы.

2. Указание явного порта кластера:

   Подключение с указанием порта (например, server1c:1541) отличается от стандартного обращения server1c, что также вызывает несовпадение сохраненных параметров.

3. Локальный запуск на сервере через RDP или RemoteApp:

   Запуск программы непосредственно на сервере через localhost или loopback-адрес 127.0.0.1 приводит к смене адреса в параметрах блокировки.

4. Подключение одной базы MS SQL / PostgreSQL к двум разным кластерам 1С:

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

Способы решения и стандартизация подключений

Рассмотрим способы устранения этой проблемы и приведения инфраструктуры к корректному виду.

1. Стандартизация строк подключения

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

1. Централизованный файл списков баз (.v8i): Создайте общий сетевой файл списка информационных баз или распространяйте его на рабочие станции с помощью групповых политик (GPO). Это исключит человеческий фактор при ручном добавлении баз.
2. Настройка CNAME в DNS: Чтобы избежать применения файла hosts на локальных компьютерах и проблем при смене IP-адреса сервера, создайте CNAME-запись на корпоративном DNS-сервере. Это позволит задать постоянное доменное имя для сервера 1С.

2. Отключение проверки имени сервера в БСП

Если в вашей инфраструктуре неизбежны различия в именах серверов, в клиент-серверном режиме можно отключить жесткую привязку к имени сервера:

1. В окне предупреждения «Информационная база была перемещена...» нажмите кнопку «Ещё».
2. Снимите флаг «Проверять имя сервера».
3. Нажмите кнопку «Информационная база перемещена».

Также эту настройку можно отредактировать напрямую через константу ПараметрыБлокировкиРаботыСВнешнимиРесурсами в режиме «Функции для технического специалиста».

Архитектурные риски и правила работы с тестовыми средами

Подключение одной физической базы данных СУБД к двум разным кластерам 1С является грубой архитектурной ошибкой и несет серьезные риски:

Конфликты управляемых блокировок: Разные кластеры 1С не синхронизируют между собой информацию о транзакционных блокировках. Это приводит к взаимным блокировкам (deadlocks) на уровне СУБД и потенциальному повреждению структуры данных.

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

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

1. Создайте отдельную копию базы данных на сервере СУБД (с новым именем базы данных).
2. Зарегистрируйте созданную копию на тестовом кластере 1С.
3. При первом входе в тестовую базу выберите вариант «Это копия информационной базы». Это сохранит блокировку регламентных заданий и работу с внешними ресурсами, предотвращая искажение рабочих данных.