Смена идентификатора информационной базы 1С

Под «сменой GUID в 1С» обычно понимают одно: сделать так, чтобы восстановленная копия базы не считалась той же самой, что рабочая. Отдельной кнопки «изменить GUID» в платформе нет — идентификатор меняется косвенно: через механизм копии базы в режиме Предприятия или через перерегистрацию базы в кластере серверов.

Ниже разберём, какие именно идентификаторы бывают у базы 1С 8.3, в каком случае какой из них нужно менять, как это сделать в файловом и клиент-серверном варианте и что при этом произойдёт с программными лицензиями.

О каком идентификаторе идёт речь

Слово «GUID» в разговорах про 1С означает сразу несколько разных вещей. Прежде чем что-то менять, определите, что именно создаёт проблему.

• 🗄️ Идентификатор информационной базы — внутренний признак, по которому конфигурация на БСП понимает, что база «та же самая». Именно он отвечает за вопрос «это копия или рабочая база?» при первом запуске перемещённой базы.
• 🖥️ Идентификатор базы в кластере серверов — GUID, который платформа присваивает базе при её регистрации в кластере (клиент-серверный вариант). Он хранится на стороне сервера 1С:Предприятия, в каталоге srvinfo, и фигурирует в консоли администрирования.
• 🔗 Внешние идентификаторы — ссылки на базу из сторонних систем (веб-сервисы, обмены, интеграции). Они опираются либо на строку подключения, либо на идентификатор базы в кластере.

GUID базы и GUID в кластере — это разные сущности. Копия файловой базы «наследует» признак копии от оригинала, а копия серверной базы получает новый идентификатор кластера только при повторной регистрации. Дальше оба случая — по отдельности.

Чтобы не менять лишнего, сначала определите свой сценарий — от него зависит, какой идентификатор трогать.

Зачем вообще менять идентификатор базы

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

• 📤 Развернули копию рабочей базы для тестирования, и она подхватила настройки обмена и ЭДО оригинала — есть риск, что тестовая база отправит реальные документы контрагентам или в учётную систему.
• 🔄 В копии сработали регламентные задания — рассылки, загрузка банка, синхронизация. Для тестовой базы это недопустимо.
• 🌐 Копия пытается использовать ту же подключённую интернет-поддержку и те же сервисы 1С, что и рабочая база, из-за чего возникают конфликты регистрации.
• 🧪 Нужно, чтобы внешняя система видела тестовый контур как отдельную базу, а не как рабочую.

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

Копия базы в режиме Предприятия: признак копии

Самый частый и самый безопасный способ — не трогать GUID вручную, а воспользоваться штатным механизмом БСП.

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

1. Разверните копию базы в отдельном каталоге или на отдельном сервере СУБД — не поверх рабочей.
2. Зайдите в неё в режиме Предприятия под пользователем с полными правами.
3. В появившемся запросе выберите вариант, что это копия (а не перемещение рабочей базы).
4. Согласитесь на отключение регламентных заданий и подтвердите, что обмены в копии работать не должны.

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

Что именно отключает этот механизм в копии:

• 🔕 Регламентные и фоновые задания — рассылки по электронной почте, автоматическая загрузка курсов валют и выписок банка, обновление статусов.
• 🔁 Синхронизацию и обмены данными — чтобы копия не выгружала документы в другие базы и не тянула данные из них.
• ✉️ Отправку документов по ЭДО — чтобы из тестового контура не ушли реальные подписанные документы контрагентам.

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

Признак копии живёт внутри самой базы, поэтому механизм одинаково работает и в файловом, и в клиент-серверном варианте. Для файловой базы это основной способ «развести» копию и оригинал: собственного идентификатора в кластере у файловой базы нет, и менять там, по сути, нечего.

Как получить новый GUID в клиент-серверном варианте (SQL)

В клиент-серверном варианте идентификатор базы в кластере присваивается при её регистрации. Отдельной операции «сменить GUID зарегистрированной базы» нет — новый идентификатор появляется, когда вы регистрируете базу в кластере заново.

Рабочий сценарий для копии серверной базы выглядит так:

1. Средствами СУБД восстановите резервную копию в новую базу данных с другим именем (например, восстановите .bak SQL Server в базу test_accounting рядом с рабочей accounting).
2. Откройте консоль администрирования серверов 1С:Предприятия (или новую консоль кластера).
3. Добавьте в кластер новую информационную базу, указав восстановленную базу данных СУБД как хранилище.
4. При добавлении платформа присвоит базе собственный идентификатор — он будет отличаться от идентификатора рабочей базы.

Так вы получаете две независимые базы в кластере с разными GUID, которые ссылаются на разные базы данных СУБД. Тот же результат даёт перерегистрация: если удалить регистрацию базы в кластере и добавить её снова, платформа сгенерирует новый идентификатор. Данные при этом не меняются — меняется только регистрационная запись в кластере.

Те же действия можно выполнить утилитой командной строки rac — она управляет кластером без графической консоли. Точные подкоманды и параметры смотрите в справке: выполните rac help и rac infobase — список операций зависит от версии платформы, поэтому придумывать синтаксис по памяти не стоит.

Идентификаторы баз кластера хранятся на стороне сервера, в служебном каталоге srvinfo (файл со списком баз кластера). Напрямую править этот список текстовым редактором не нужно и опасно: при ошибке кластер перестанет видеть базу. Все операции с регистрацией делайте через консоль или rac.

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

Про «консольные утилиты» для правки GUID

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

• Это не штатный инструмент платформы 1С, и фирма 1С его не поддерживает.
• Прямая правка внутренних идентификаторов может нарушить целостность регистрации базы в кластере или её связи с внешними системами.
• Результат сильно зависит от версии платформы — то, что сработало на одном релизе, ломает базу на другом.

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

Что будет с лицензиями после смены идентификатора

Отдельный повод для беспокойства — лицензии. Разберём по типам.

Аппаратные ключи (HASP). Привязаны к USB-ключу, а не к базе. Смена идентификатора базы на них никак не влияет: ключ работает, пока вставлен в сервер или компьютер.

Программные лицензии. Привязаны к параметрам компьютера, а не к GUID базы. Поэтому сама по себе смена идентификатора базы лицензию не «сбрасывает». Проблемы возникают в другом случае — когда вы переносите базу на новый сервер: там параметры оборудования другие, и программную лицензию придётся активировать заново.

Повторная активация программной лицензии возможна ограниченное число раз. Если лимит исчерпан, новый пин-код для активации выдаёт центр лицензирования — обращаться нужно через партнёра, у которого покупалась лицензия.

Вывод простой: смена идентификатора базы сама по себе лицензии не ломает. На лицензии влияет переезд на другое оборудование, а не новый GUID.

Частые ошибки

Даже при аккуратной работе с копиями легко наступить на одни и те же грабли.

• 🔴 Развернули копию поверх рабочей базы. Всегда разворачивайте копию в отдельный каталог или отдельную базу данных СУБД, иначе рискуете потерять рабочие данные.
• 🔴 Не пометили базу как копию и включили обмены. Тестовая база отправила реальные документы в учётную систему или контрагентам.
• 🔴 Перерегистрировали базу в кластере в рабочее время. Все пользователи вылетели из сеансов.
• 🔴 Понадеялись на стороннюю утилиту без резервной копии. После неудачной правки служебных файлов кластер перестал видеть базу, а отката нет.
• 🔴 Перенесли базу на новый сервер и забыли про лицензию. Работа встала, пока не выполнена повторная активация.

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

Частые вопросы