Как перенести кластер 1С на другой сервер

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

Кластер 1С состоит из двух логических частей: службы агента сервера 1С (ragent) с рабочими процессами и реестром кластера, а также баз данных на сервере СУБД (MS SQL, PostgreSQL и др.). В зависимости от архитектуры СУБД может располагаться на той же машине или отдельно — от этого зависит объём работ. Ниже разобран полный сценарий переноса, включая случаи, когда двигается только кластер, только СУБД или всё сразу.

Все операции выполняются с правами администратора, а перед началом обязательно делается полная резервная копия баз и файлов реестра кластера. Это единственная страховка, которая позволит откатиться, если что-то пойдёт не по плану.

Подготовка: что проверить и забэкапить до переноса

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

Убедитесь, что на новом сервере установлена та же версия платформы 1С, что и на старом, включая номер сборки. Перенос с одновременным обновлением платформы — частая причина проблем: если что-то пойдёт не так, вы не сможете быстро понять, виноват перенос или новая версия. Обновление выполняйте отдельным этапом уже после успешной миграции.

Сделайте резервные копии: полный бэкап всех баз данных штатными средствами СУБД и копию каталога реестра кластера srvinfo (в Windows обычно это C:\Program Files\1cv8\srvinfo, в Linux — /opt/1cv8/... или каталог, указанный при запуске агента). Также сохраните конфигурационные файлы, если они изменялись: nethasp.ini для настройки поиска лицензий, скрипты регламентных заданий, настройки внешних компонент.

Установка платформы и служб на новом сервере

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

Проверьте сетевые настройки: порты кластера (по умолчанию 1540, 1541, диапазон 1560–1591) должны быть открыты в брандмауэре нового сервера и доступны с машин пользователей и с сервера СУБД. Если в вашей сети используются ограничения по IP, обновите правила с учётом нового адреса сервера.

Отдельно проверьте права учётной записи службы агента на сервере СУБД: она должна иметь доступ к базам данных с теми же полномочиями, что и раньше. Если СУБД использует Windows-аутентификацию, новая учётная запись должна быть заведена в SQL Server с правами на соответствующие базы.

Перенос реестра кластера и информационных баз

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

Способ 1: копирование каталога srvinfo

Остановите службу агента сервера 1С на старом и на новом сервере. Скопируйте каталог srvinfo со старого сервера на новый, заменив созданный при установке пустой каталог. Запустите службу агента на новом сервере и откройте консоль кластера: все базы, настройки и список администраторов должны появиться автоматически.

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

Способ 2: создание баз в консоли вручную

Если баз немного, зарегистрируйте их в консоли кластера заново: создайте новую информационную базу, укажите имя базы на сервере СУБД, сервер СУБД, тип СУБД и учётные данные. Важно: при создании укажите, что база данных уже существует — не создавайте новую пустую базу поверх существующей. Этот способ исключает перенос «мусора» из старого реестра и подходит при смене версии ОС.

1. 1
   Зафиксируйте настройки кластера и сделайте бэкапы баз данных и каталога srvinfo
2. 2
   Установите на новом сервере платформу той же версии и откройте порты кластера
3. 3
   Остановите агенты на обоих серверах, перенесите srvinfo или пересоздайте базы в консоли
4. 4
   Перенесите базы данных СУБД и обновите параметры подключения в свойствах баз
5. 5
   Запустите кластер, проверьте вход пользователей и регламентные задания
6. 6
   Переключите DNS или ярлыки пользователей на новый сервер

Перенос баз данных СУБД

Если сервер СУБД переезжает вместе с кластером, базы данных переносятся штатными средствами. Для MS SQL Server это либо backup/restore, либо detach/attach с копированием файлов MDF/LDF. Способ backup/restore безопаснее: исходная база остаётся нетронутой и доступной для отката. Для PostgreSQL используйте pg_dump/pg_restore или физическое копирование каталога данных при остановленной службе.

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

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

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

Переключение пользователей и публикации

Когда кластер и базы работают на новом сервере, нужно перенаправить пользователей. Если вы создали DNS-запись со старым именем сервера, клиентские подключения переключатся прозрачно после обновления DNS-кэша. Если имя изменилось, обновите списки баз на клиентах: в файле ibases.v8i или через групповые политики, если списки распространяются централизованно.

Не забудьте про смежные компоненты: публикации на веб-сервере (файлы default.vrd указывают на имя сервера кластера), настройки сервера хранилища конфигураций, внешние источники данных, интеграционные сервисы и планировщики, которые обращаются к кластеру по имени или IP. Составьте заранее список таких точек интеграции и пройдитесь по нему после переноса.

Проверьте лицензии: программные лицензии сервера 1С привязываются к параметрам оборудования и при переезде на новый сервер могут стать недействительными. Потребуется повторная активация пин-кодом из комплекта поставки. USB-ключи HASP переносятся физически — не забудьте переставить ключ и настроить менеджер лицензий на новом сервере.

Проверка результата и откат

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

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

Контрольные точки

Как проверить результат

Вход в информационные базы

Норма

Пользователь входит, видит актуальные данные, документы проводятся

Тревожный признак

Ошибка соединения с СУБД или пустая база — проверьте параметры подключения

Регламентные задания

Норма

Задания выполняются по расписанию без ошибок в журнале

Тревожный признак

Задания зависают или падают — проверьте права и настройки рабочих процессов

Лицензии

Норма

Клиенты получают лицензии, в консоли виден активный сервер

Тревожный признак

Ошибка 'не найдена лицензия' — требуется активация программной лицензии или настройка ключа

Веб-публикации и обмены

Норма

Веб-клиент открывается, интеграции обмениваются данными

Тревожный признак

Ошибка подключения к кластеру — обновите default.vrd и адреса в интеграциях

FAQ

Можно ли перенести кластер 1С без остановки работы пользователей?

Полностью без простоя перенос возможен только при использовании репликации на уровне СУБД (например, Always On в MS SQL) с последующим переключением. В типовом сценарии потребуется короткое окно простоя на время финального копирования данных и переключения адресов — обычно его планируют на вечер или выходные.

Что делать, если версия платформы на новом сервере новее?

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

Потеряются ли настройки кластера при переносе srvinfo?

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

Нужно ли заново активировать лицензии 1С после переезда?

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

Как перенести кластер, если сервер СУБД остаётся на месте?

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

Сколько времени держать старый сервер после переноса?

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