Каждый день появляется сообщение «Информационная база была перемещена» в 1С: как решить проблему

← На главную

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

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

Как 1С узнает, что база была «перемещена»

Для начала проанализируем внутренний механизм защиты БСП. Данный функционал разработан для того, чтобы предотвратить случайный запуск тестовых копий под видом рабочих баз. Если запустить копию базы без ограничений, она может начать отправлять реальные письма клиентам, синхронизироваться с сайтами, отправлять данные в государственные системы маркировки («Честный Знак», ЕГАИС, ВетИС) или обмениваться данными с другими рабочими конфигурациями. Это может привести к катастрофическим последствиям для бизнес-процессов.

Механизм контроля перемещения базы работает по-разному в зависимости от режима работы:

В файловом режиме система создает специальный файл маркировки DoNotCopy.txt в каталоге базы данных. В нем регистрируется уникальный идентификатор (GUID). При запуске сеанса этот идентификатор сравнивается с тем, который записан в самой базе данных. Если файлы удаляются или GUID не совпадает, база считается копией.
В клиент-серверном режиме файл DoNotCopy.txt не создается. Вместо этого БСП ориентируется исключительно на строку соединения с информационной базой, которую возвращает функция платформы СтрокаСоединенияИнформационнойБазы(). При первом запуске или после того, как администратор нажимает кнопку «Информационная база перемещена», текущие параметры подключения (имя сервера и имя базы данных на сервере 1С) записываются в специальный регистр сведений или константу. При каждом последующем входе система сравнивает текущую строку соединения с сохраненным эталоном.

Причины ложного срабатывания в клиент-серверном варианте

Выясним причину, по которой проверка эталонной строки соединения дает сбой, вызывая ежедневное появление окна блокировки. Основная проблема заключается в разнородности строк подключения у различных пользователей и служб. Система крайне чувствительна к любым изменениям в написании параметров соединения.

Рассмотрим наиболее распространенные сценарии расхождения строк подключения:

Различные имена серверов в списках баз: У одного пользователя в тонком клиенте прописан IP-адрес сервера (например, 192.168.1.100), у другого — короткое сетевое имя (app-server), а у третьих — полное доменное имя (FQDN, например, app-server.company.local). Для платформы 1С это три абсолютно разные строки подключения.
Различие в указании портов кластера: По умолчанию кластер 1С работает на порту 1541. Если у части пользователей база прописана как app-server/base_prod, а у другой части (или в настройках веб-сервера) явно указан порт — app-server:1541/base_prod, то при входе пользователя с «нетипичной» строкой БСП зафиксирует изменение параметров и заблокирует внешние ресурсы.
Использование веб-клиента: При публикации базы на веб-сервере (IIS или Apache) строка соединения для веб-клиентов формируется по правилам URL-адресов. Когда пользователь заходит через браузер, БСП считывает строку подключения, которая не содержит имя сервера 1С в привычном формате, что мгновенно триггерит режим копии.
Выполнение регламентных заданий: Когда на сервере запускаются фоновые и регламентные задания, они выполняются в контексте самого сервера 1С. В этот момент строка соединения может определиться локально как localhost или 127.0.0.1, что снова приводит к несовпадению с сохраненным эталоном, где прописано реальное имя сервера.

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

Пошаговые способы решения проблемы

Проанализируем три основных способа устранения этой проблемы — от простых пользовательских настроек до программного вмешательства.

Способ 1. Унификация строк подключения пользователей

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

Определите единый стандарт обращения к серверу 1С. Лучше всего использовать полное доменное имя сервера (FQDN) без явного указания порта (если используется стандартный порт 1541). Например: Srvr="app-server.company.local";Ref="base_prod";.
Исключите использование IP-адресов и коротких имен в настройках подключения у пользователей.
Для централизованного управления списками баз используйте общий список информационных баз (файл с расширением .v8i), расположенный на сетевом ресурсе. Настройте запуск 1С у пользователей так, чтобы они получали список баз из этого единого файла. Это исключит человеческий фактор при ручном добавлении баз.
Убедитесь, что в настройках публикации на веб-сервере (файл default.vrd) параметры подключения к кластеру 1С прописаны точно так же, как и в общем списке баз.

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

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

Мы можем указать системе, чтобы она проверяла только имя базы данных (параметр Ref), полностью игнорируя различия в написании имени сервера (параметр Srvr). Для этого выполните следующие действия:

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

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

Способ 3. Программное отключение проверки (для разработчиков)

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

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

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


&Вместо("УстановленаБлокировкаРаботыСВнешнимиРесурсами")
Функция Мой_УстановленаБлокировкаРаботыСВнешнимиРесурсами()
    // Принудительно отключаем блокировку работы с внешними ресурсами,
    // предотвращая появление окна о перемещении базы
    Возврат Ложь;
КонецФункции

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


&Вместо("ПараметрыСоединенияСовпадают")
Функция Мой_ПараметрыСоединенияСовпадают(Знач Параметры1, Знач Параметры2)
    // Приводим обе строки подключения к нижнему регистру
    Строка1 = НРег(Параметры1);
    Строка2 = НРег(Параметры2);
    
    // Удаляем порты из строк подключения для корректного сравнения
    Строка1 = СтрЗаменить(Строка1, ":1541", "");
    Строка2 = СтрЗаменить(Строка2, ":1541", "");
    
    // Выполняем стандартное сравнение очищенных строк
    Возврат Строка1 = Строка2;
КонецФункции

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