Переход сервера 1С:Предприятия на новую платформу и обновление баз без простоя

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

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

1. Подготовка: проверка совместимости и резервные копии

Начните с вопроса «зачем». Обычно платформу обновляют, потому что новый релиз конфигурации требует более свежую версию. Минимальный номер платформы указан в описании релиза конфигурации. Если на сервере стоит 8.3.24, а релиз требует номер не ниже 8.3.25, сначала платформа, потом конфигурация — не наоборот.

Что проверить до окна работ:

• 🔢 Текущая версия. Она видна в консоли кластера, в свойствах рабочего сервера и в окне «О программе» у клиента.
• 🗄️ Версия СУБД. Новая платформа может не поддерживать слишком старую сборку PostgreSQL или MS SQL. Список поддерживаемых СУБД смотрите в описании версии платформы.
• 🔑 Лицензии. Программная лицензия сервера привязана к параметрам оборудования. Смена версии платформы её не сбрасывает, но если вы одновременно меняете железо или виртуальную машину — заложите время на повторную активацию.
• 🔌 Внешние интеграции. COM-соединение (comcntr.dll), веб-публикации на IIS или Apache, внешние обработки обмена — всё это привязано к конкретной версии и требует перенастройки.

Резервные копии

Копий нужно три, и каждая закрывает свой риск:

Бэкап средствами СУБД делается быстрее выгрузки .dt и не требует остановки работы пользователей. Выгрузка .dt полезна как страховка от проблем на уровне самой СУБД.

Каталог srvinfo по умолчанию лежит в C:\Program Files\1cv8\srvinfo. Внутри — файл 1CV8Clst.lst с реестром кластера: список баз, рабочих серверов, администраторов. Копируйте его при остановленной службе, иначе файл может оказаться в промежуточном состоянии.

2. Дистрибутив сервера: какой архив брать

Дистрибутивы платформы скачиваются с портала пользовательской поддержки по договору ИТС. Для клиент-серверной схемы нужны два комплекта:

• 🖥️ Сервер. Для Windows — «Технологическая платформа 1С:Предприятия (64-bit) для Windows», в нём есть компоненты сервера. Для Linux — отдельные пакеты deb или rpm под нужную разрядность.
• 💻 Клиент. Для рабочих мест обычно хватает тонкого клиента . Толстый клиент и Конфигуратор нужны тем, кто администрирует и дорабатывает базы.

Разрядность сервера — 64 бита. 32-битный сервер упирается в ограничение памяти рабочего процесса и для рабочих нагрузок давно не используется. Разрядность клиентов может отличаться от серверной: 32-битный тонкий клиент спокойно работает с 64-битным сервером, если совпадает номер версии.

💡 Сохраните дистрибутив в сетевую папку, доступную всем рабочим местам. Она понадобится для автоматической установки клиентов на шаге 4.

3. Установка новой платформы на сервер

Новая версия ставится в отдельный каталог вида C:\Program Files\1cv8\8.3.xx.xxxx и не затирает старую. Это и есть ваш план отката: пока старая версия не удалена, вернуться на неё можно за пять минут.

Остановка работы с базами

Остановка службы агента разрывает все сеансы. Поэтому сначала выгоните пользователей аккуратно:

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

Установка компонентов

Запустите setup.exe из серверного дистрибутива. На шаге выбора компонентов отметьте:

• «Сервер 1С:Предприятия»;
• «Модули расширения веб-сервера» — если базы опубликованы на веб-сервере;
• «Администрирование сервера 1С:Предприятия» — для консоли.

Установщик предложит установить сервер как службу Windows и спросит пользователя, от имени которого служба будет работать. Используйте ту же учётную запись, что и у текущей службы: у неё уже есть права на каталог srvinfo и, если надо, на сетевые ресурсы.

Перевод службы агента на новую версию

Это ключевой шаг, на котором чаще всего ошибаются. Служба агента указывает на ragent.exe конкретной версии. Если оставить её как есть, сервер продолжит работать на старой платформе, а клиенты с новой версией получат ошибку несовпадения версий.

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

:: остановить и удалить регистрацию старой службы
"C:\Program Files\1cv8\8.3.24.xxxx\bin\ragent.exe" -rmsrvc

:: зарегистрировать службу новой версии
"C:\Program Files\1cv8\8.3.25.xxxx\bin\ragent.exe" -instsrvc -usr ".\USR1CV8" -pwd "пароль" -port 1540 -regport 1541 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"

:: запустить
"C:\Program Files\1cv8\8.3.25.xxxx\bin\ragent.exe" -start

Номера версий подставьте свои, порты — те, что используются у вас сейчас. Если ключи вызывают сомнение, запустите ragent.exe /? — агент выведет список поддерживаемых параметров. Параметр -d обязательно указывает на прежний каталог srvinfo: так новый агент подхватит реестр кластера со всеми базами.

После запуска откройте services.msc и посмотрите путь к исполняемому файлу в свойствах службы. Там должен быть каталог новой версии.

Если сервер на Linux

Начиная с версии 8.3.21 сервер на Linux управляется через systemd, а служба получает имя с номером версии. Старую службу останавливают и отключают, новую включают:

sudo systemctl stop srv1cv8-8.3.24.xxxx@default
sudo systemctl disable srv1cv8-8.3.24.xxxx@default
sudo systemctl enable srv1cv8-8.3.25.xxxx@default
sudo systemctl start srv1cv8-8.3.25.xxxx@default

Точное имя модуля проверьте командой systemctl list-unit-files | grep srv1cv8. Каталог данных кластера у новой службы должен совпадать со старым.

Консоль, COM и веб-публикации

После смены версии консоль администрирования часто перестаёт подключаться к кластеру. Причина — в системе зарегистрирована radmin.dll старой версии. Перерегистрируйте её от имени администратора:

regsvr32 "C:\Program Files\1cv8\8.3.25.xxxx\bin\radmin.dll"

Тем же способом перерегистрируют comcntr.dll, если к базам подключаются внешние программы через COM. Для веб-публикаций откройте файл default.vrd или настройки модуля веб-сервера и проверьте путь к wsap24.dll: он тоже указывает на каталог конкретной версии.

Если вы управляете кластером через rac, служба сервера администрирования ras тоже должна быть новой версии. Проверка связи — rac cluster list.

4. Настройка кластера и клиентских мест после обновления

Когда служба запущена на новой версии, откройте консоль кластера и пройдитесь по свойствам.

• 🧩 Рабочий сервер. Диапазон портов рабочих процессов, параметры отказоустойчивости и требования назначения функциональности хранятся в свойствах рабочего сервера, а не кластера. Убедитесь, что значения перенеслись.
• 🧠 Ограничения памяти. Проверьте объём памяти рабочих процессов и критический объём. Если до обновления процессы упирались в лимит, самое время его пересмотреть.
• 🔓 Блокировки баз. Пока не снимайте — они понадобятся на этапе обновления конфигурации.

Брандмауэр: агент слушает 1540, менеджер кластера — 1541, рабочие процессы — диапазон 1560–1591 по умолчанию. Если правила привязаны к программе, а не к порту, их придётся пересоздать для нового ragent.exe, rmngr.exe и rphost.exe.

Обновление клиентов

Вариантов три, выбирайте по масштабу:

Для автоустановки в общий файл 1CEStart.cfg (на клиентах он лежит в C:\ProgramData\1C\1CEStart) добавляют строку DistributiveLocation=\\server\1c\distr. Стартер при запуске видит, что для базы нужна новая версия, и ставит её из этой папки.

В списке баз у клиента в свойствах базы есть поле «Версия 1С:Предприятия». Если там жёстко прописан старый номер, стартер будет запускать старую платформу. Оставьте поле пустым или укажите маску вида 8.3.25.

5. Обновление конфигурации баз на сервере

Платформа обновлена, теперь очередь конфигурации. Делайте это под установленной блокировкой сеансов: Конфигуратор пускает в базу по коду разрешения из блокировки. Для запуска с кодом добавьте в строку запуска параметр /UC <код>.

1. Откройте базу в Конфигураторе и проверьте, что конфигурация на поддержке. Если менялась — будет режим сравнения и объединения, на него закладывайте больше времени.
2. Выполните Конфигурация → Поддержка → Обновить конфигурацию и укажите файл .cfu нужного релиза. Файл .cfu применяется только к тем версиям, которые перечислены в его описании. Если ваша версия старее, обновляйтесь цепочкой через промежуточные релизы.
3. Нажмите Конфигурация → Обновить конфигурацию базы данных (F7). Здесь платформе нужен монопольный доступ — поэтому сеансы и были заблокированы.
4. Запустите базу в режиме 1С:Предприятие от имени администратора. Откроется обработка обновления данных, дождитесь её окончания.
5. Повторите для каждой базы.

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

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

6. Проверка и запуск в работу

Не снимайте блокировку сразу. Сначала короткий прогон силами двух-трёх человек, которые знают свои участки.

Минимальный набор проверок:

• 📄 Открыть и провести документ из каждого ключевого раздела: продажи, покупки, банк, зарплата.
• 🖨️ Сформировать печатную форму и основной отчёт — например, оборотно-сальдовую ведомость.
• 🔄 Запустить обмен данными вручную, если базы обмениваются с другими системами.
• ⏱️ Вручную выполнить важное регламентное задание и посмотреть журнал регистрации на ошибки.
• 🌐 Войти через веб-клиент или мобильное приложение, если они используются.

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

План отката

Если обнаружилась ошибка, которую не исправить быстро, откат выглядит так:

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

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

7. Частые ошибки при обновлении сервера

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