Как обновить платформу 1С на сервере

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

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

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

Подготовка: что проверить до начала обновления

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

Далее проверьте совместимость. Конфигурация, рассчитанная на платформу 8.3.20, как правило, запустится на 8.3.22, но обратная ситуация (запуск базы, обновлённой под новую платформу, на старой) невозможна. Также уточните разрядность: если сервер 1С 64-разрядный, ставьте 64-разрядный дистрибутив, смешивание разрядностей сервера и СУБД-клиента частая причина сбоев.

Обязательно согласуйте окно обновления с пользователями. Во время установки служба агента сервера будет перезапущена, все сеансы разорвутся, а незавершённые транзакции могут привести к потере несохранённых данных в открытых документах.

Резервное копирование перед обновлением

Единственный надёжный способ защититься при обновлении сервера — полная резервная копия баз на уровне СУБД. Для MS SQL Server это задача Backup в SQL Server Management Studio или регламентное задание, для PostgreSQL — утилита pg_dump. Копирование через выгрузку .dt из конфигуратора допустимо как дополнительная мера, но для больших баз оно медленное и не заменяет копию средствами СУБД.

Помимо баз, сохраните каталог srvinfo (обычно C:\Program Files\1cv8\srvinfo или соответствующий путь в Linux) — в нём хранится реестр кластера: список баз, настройки, параметры сеансов. Если при обновлении что-то пойдёт не так с самим кластером, этот каталог позволит быстро вернуть конфигурацию сервера.

Получение и установка дистрибутива платформы

Дистрибутив платформы скачивается с портала 1С (portal.1c.ru) в разделе обновлений программ — нужен пункт «Технологическая платформа 1С:Предприятия» для вашей версии и разрядности. Для Windows это архив с установщиком, для Linux — пакеты .deb или .rpm. Доступ к скачиванию требует действующего договора 1С:ИТС.

На сервере Windows установка выполняется запуском setup.exe от имени администратора. Установщик сам определит установленные компоненты и предложит обновить их: «Сервер 1С:Предприятия», «Модули расширения веб-сервера», «Администрирование сервера» и другие. Оставьте отмеченными те же компоненты, что были установлены ранее. Во время установки служба агента будет остановлена и запущена заново автоматически — все активные сеансы разорвутся.

На Linux обновление выполняется установкой новых пакетов поверх существующих (например, через dpkg -i или rpm -U), с последующим перезапуском службы srv1cv8. Порядок пакетов: сначала common, затем server, затем дополнительные компоненты.

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

Обновление кластера и службы агента

Особенность сервера 1С в том, что разные версии платформы могут существовать на одной машине параллельно: каждая версия регистрирует свою службу агента со своим портом (например, 8.3.22 — порты 1540-1541, другая версия — 2540-2541). Это позволяет выполнять поэтапный переход: поднять новый кластер рядом со старым и переносить базы постепенно.

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

Get-Service "1C:Enterprise 8.3 Server Agent*" | Select-Object Name, Status

Отдельно проверьте версию в свойствах исполняемого файла ragent.exe в каталоге новой платформы (Program Files\1cv8\<версия>\bin) — она должна соответствовать установленному релизу.

Обновление клиентских мест и веб-компонентов

После обновления сервера клиентские приложения старой платформы могут подключаться, только если версии совместимы, но корректная практика — привести клиентов к той же версии, что и сервер. На терминальном сервере платформу устанавливают так же, через setup.exe, выбирая компонент «Тонкий клиент» или «1С:Предприятие» (толстый клиент) в зависимости от используемого режима.

Для массового обновления рабочих мест удобны групповые политики (GPO) с установкой MSI-пакетов из дистрибутива или системы развёртывания ПО. Если базы опубликованы на веб-сервере, не забудьте переопубликовать их после обновления: модули расширения веб-сервера обновляются вместе с платформой, и публикация должна ссылаться на новую версию компоненты wsisapi.dll / wsap24.

Проверка результата после обновления

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

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

Откат и частые вопросы

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