Администрирование · 11 мин
Как определить, что база 1С является копией
Как установить, что база 1С является копией: проверка идентификатора базы, журнала регистрации, констант, строки подключения и других признаков клонирования.
Копии баз 1С создаются постоянно: для тестирования обновлений, обучения сотрудников, разработки доработок, восстановления после сбоев. Проблема возникает, когда копия начинает работать как «живая» база — в неё вносят документы, она участвует в обменах, рассылает отчёты. Тогда важно быстро установить, что перед вами именно клон, а не рабочая база.
Признаки копии разбросаны по нескольким местам: внутренний идентификатор информационной базы, параметры обмена данными, журнал регистрации, константы и системные настройки. Ни один признак в отдельности не даёт стопроцентной гарантии, поэтому проверку стоит проводить комплексно.
Ниже разобраны конкретные способы проверки для файловых и клиент-серверных баз, типовые признаки клонирования и действия, которые нужно выполнить, чтобы копия не мешала работе основной базы.
Что технически делает базу копией
Копия создаётся двумя способами: выгрузкой в файл .dt через конфигуратор или прямым копированием каталога файловой базы (файла 1Cv8.1CD) либо бэкапа средствами СУБД для клиент-серверного варианта. Во всех случаях внутри новой базы сохраняется внутренний идентификатор, который платформа присвоила оригиналу при создании.
Именно этот идентификатор (GUID информационной базы) — главный маркер. Две базы с одинаковым GUID для платформы и механизмов обмена являются «одной и той же» базой. Это критично для планов обмена: узлы обмена привязаны к идентификатору, и копия будет считаться тем же узлом, что и оригинал.
Важно не путать внутренний идентификатор с именем базы в списке запуска или именем базы на сервере СУБД — это внешние атрибуты, их легко переименовать, и они ничего не говорят о происхождении данных.
Проверка через идентификатор информационной базы
Самый простой способ узнать GUID базы без программирования — через конфигуратор. Откройте конфигуратор, перейдите в меню «Администрирование» и посмотрите доступные сведения о базе. В ряде версий платформы идентификатор можно получить через стандартные функции или через внешнюю обработку, возвращающую значение идентификатора базы.
Для программного получения идентификатора используется стандартная функция встроенного языка, возвращающая уникальный идентификатор информационной базы. Её можно выполнить через внешнюю обработку, консоль кода или отчёт, доступный во многих типовых конфигурациях.
- 1Откройте первую базу в режиме предприятия или конфигуратора.
- 2Запустите обработку или консоль кода и получите идентификатор информационной базы.
- 3Повторите те же действия во второй базе.
- 4Сравните значения: полное совпадение GUID означает, что одна база является копией другой.
- 5Зафиксируйте результат и дату проверки для дальнейших действий.
Если идентификаторы совпадают — факт клонирования установлен. Если различаются, базы создавались независимо, даже если данные в них похожи (например, обе загружены из одного шаблона пустой конфигурации).
Признаки копии в параметрах обмена и константах
Если база участвует в обмене данными (РИБ, обмен с сайтом, синхронизация между конфигурациями), откройте настройки обмена. В копии коды узлов планов обмена совпадают с кодами оригинала. Платформа при попытке обмена может выдать предупреждение о том, что база-приёмник не соответствует ожидаемому узлу — это типичный признак работы с клоном.
Проверьте также константы и настройки, где фиксируется «производственность» базы:
- префикс информационной базы — совпадает с префиксом оригинала, если его не меняли сознательно;
- настройки отправки почты — копия может продолжать рассылать письма и отчёты реальным контрагентам;
- настройки подключения к внешним сервисам (ЭДО, банк-клиент, обмен с сайтом) — в копии они остаются активными и указывают на боевые сервисы;
- регламентные задания — в клиент-серверной копии задания могут выполняться по расписанию и дублировать операции основной базы.
Анализ журнала регистрации
Журнал регистрации копируется вместе с базой, поэтому история событий в клоне обрывается на момент создания копии. Откройте журнал регистрации (в конфигураторе или через раздел «Администрирование» в режиме предприятия) и посмотрите на характер записей.
Косвенные признаки копии в журнале:
- после некоторой даты в журнале только тестовые действия, отладочные сеансы, работа одного разработчика;
- есть события загрузки данных или восстановления, после которых меняется характер активности;
- отсутствуют штатные сеансы обычных пользователей, характерные для рабочей базы.
Отдельно проверьте дату и время последнего осмысленного события. Если в «рабочей» базе последняя активность датируется моментом создания бэкапа, а реальные пользователи уверены, что работают каждый день, — скорее всего, они подключены к другой базе, а вы смотрите копию.
Проверка по данным и ссылкам объектов
Ещё один способ установить факт клонирования — сравнить сами данные. В копии совпадают внутренние ссылки (GUID) всех объектов: документов, справочников, пользователей. Если взять один и тот же документ в двух базах и сравнить его уникальный идентификатор, совпадение подтвердит общее происхождение.
Практический приём: найдите в обеих базах один и тот же документ по номеру и дате, затем получите его ссылку в виде GUID через консоль запросов или обработку. Совпадение GUID при совпадении номеров говорит о копии; совпадение только номеров при разных GUID — о независимом вводе или переносе данных обработками.
Как отличить копию от рабочей базы
GUID уникален, не совпадает с другими базами компании
GUID совпадает с GUID другой базы — это клон
Непрерывная история штатной работы пользователей
История обрывается на дату создания копии, дальше только тестовые сеансы
Актуальные боевые настройки, обмены выполняются успешно
Настройки указывают на боевые сервисы, но обмен не выполнялся или даёт ошибки узла
Регулярные сеансы всех сотрудников
Сеансы только администратора или разработчика
Особенности для файловых и клиент-серверных баз
Для файловых баз дополнительный признак — история файла 1Cv8.1CD. Сравните дату создания файла, его расположение и наличие рядом архивных копий с датами в именах. Файл, скопированный в папку вида «База_копия» или «База_тест», почти наверняка клон, но окончательное подтверждение всё равно даёт только внутренний идентификатор.
В клиент-серверном варианте полезно сверить имя базы на сервере СУБД и список баз в консоли кластера 1С. Типичная ситуация: на SQL-сервере лежат базы с похожими именами (например, рабочая и её тестовый слепок), а пользователи подключаются по старой строке подключения. Проверьте, к какой именно базе ведёт запись в списке информационных баз пользователя.
Что делать после подтверждения, что база — копия
Если установлено, что база является копией и должна работать как тестовая, приведите её в безопасное состояние. Отключите выполнение регламентных и фоновых заданий, очистите или закомментируйте настройки обменов, почты, ЭДО и банковских подключений. Во многих типовых конфигурациях есть штатный механизм блокировки регламентных заданий при восстановлении из копии — убедитесь, что он сработал.
Полезно явно пометить копию для пользователей: измените заголовок системы или добавьте в наименование организации пометку «ТЕСТ». Это снижает риск ввода реальных документов в тестовую базу.
Как выбрать действие
Если же две «живые» базы оказались копиями и в обе вносились документы, потребуется сведение данных. Это трудоёмкая операция: определите базу-источник истины, выгрузите из второй базы документы за период расхождения и загрузите их штатными средствами переноса, контролируя дубли по GUID.
Частые вопросы
Можно ли определить точную дату создания копии?
Точной отметки «база скопирована» платформа не хранит. Дату можно оценить косвенно: по последнему событию штатной работы в журнале регистрации перед началом тестовой активности, по дате создания файла 1Cv8.1CD для файловых баз или по дате бэкапа на сервере СУБД, из которого база восстановлена.
Меняется ли идентификатор базы при обновлении конфигурации?
Нет. Обновление конфигурации, реструктуризация, тестирование и исправление не меняют внутренний идентификатор информационной базы. Новый GUID база получает только при создании новой информационной базы, а не при загрузке данных в существующую.
Что будет, если две копии одновременно работают в обмене РИБ?
Узлы обмена привязаны к идентификатору базы, поэтому обе копии будут претендовать на один и тот же узел. Это приводит к ошибкам соответствия узлов, потере или задвоению сообщений обмена. Одну из баз нужно отключить от обмена и при необходимости заново создать для неё узел.
Можно ли «отвязать» копию, сменив её идентификатор?
Штатной кнопки смены GUID базы нет. На практике применяют создание новой пустой базы с последующей загрузкой данных из .dt или переносом данных штатными обработками — тогда новая база получает собственный идентификатор. Прямые манипуляции с идентификатором не документированы и рискованны.
Как быстро проверить, к какой базе подключён пользователь?
В режиме предприятия откройте сведения о программе: там отображается режим работы (файловый или клиент-серверный), каталог базы или имя сервера и имя базы. Сверьте эти данные с эталонной строкой подключения рабочей базы — расхождение укажет на подключение к копии.
Опасно ли просто открыть копию базы?
Само открытие в режиме предприятия безопасно, если в копии отключены регламентные задания. Риск представляет клиент-серверная копия с активными заданиями: фоновые процессы могут начать обмены и рассылки без участия пользователя. Поэтому первый запуск копии лучше выполнять с заблокированными регламентными заданиями.
Что важно запомнить
Главный признак копии базы 1С — совпадение внутреннего идентификатора (GUID) информационной базы с оригиналом. Дополнительные признаки: совпадающие коды узлов обмена, обрыв журнала регистрации на дате создания копии, идентичные GUID объектов. После подтверждения копии отключите регламентные задания и обмены, пометьте базу как тестовую, чтобы избежать дублирования операций и рассылок.