К статье
Практический материал

Администрирование · 11 мин

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

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

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

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

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

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

Третий шаг — определить текущую архитектуру: какая версия платформы установлена, какие службы агента сервера 1С запущены, на каких портах работают кластеры, где находится каталог srvinfo с реестром кластера. Эти сведения понадобятся, если потребуется откат.

Выбор способа обновления: рядом или поверх

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

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

Второй сценарий — обновление «поверх» в пределах одной линейки версий, когда старая платформа удаляется, а новая занимает её место. Такой вариант проще, но откат потребует повторной установки прежней версии, что занимает время в критической ситуации.

Сравнение вариантов

Установка рядом со старой версией

Подходит для продуктивных серверов: быстрый откат переключением кластера. Требует свободных портов и места на диске

Обновление поверх

Подходит для тестовых серверов и небольших установок. Проще, но откат медленнее и рискованнее

Обновление через тестовый стенд

Новая версия сначала разворачивается на копии сервера, проверяется, затем переносится в продуктив. Максимальная надёжность, но требует дополнительных ресурсов

Загрузка и установка новой версии платформы

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

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

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

На Linux установка выполняется пакетным менеджером. Например, для deb-based систем порядок такой:

bash
sudo dpkg -i server*.deb
sudo systemctl status srv1cv8-*

После установки нужно убедиться, что служба агента сервера новой версии запущена и слушает свои порты (по умолчанию диапазон начинается с 1540 для агента; при установке нескольких версий порты должны различаться, иначе служба не стартует).

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

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

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

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

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

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

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

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

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

Служба агента сервера новой версии
Норма

Служба запущена, кластер открывается в консоли

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

Служба падает или не стартует — проверять порты и логи

Вход в базу под пользователем
Норма

База открывается, сеанс отображается в консоли

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

Ошибка несовместимости версий или конвертации

Фоновые и регламентные задания
Норма

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

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

Задания зависают или завершаются с ошибкой

Веб-доступ и публикации
Норма

База открывается через браузер и тонкий клиент по вебу

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

Ошибка модуля веб-расширения — нужна перепубликация

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

Откат на предыдущую версию

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

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

Маршрут решения

Как выбрать действие

Новая платформа установлена, но базы ещё не открывалисьПросто удалите новую версию или не переводите на неё базы — рисков нет
Базы сконвертированы, но ошибки незначительныИщите исправление: обновление конфигурации, патчи платформы, настройку режима совместимости
Критическая ошибка сразу после конвертацииОстановите работу пользователей и восстановите базу из копии, сделанной до обновления

Типичные ошибки при обновлении платформы

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

Типичные ошибки
01
Обновление без резервной копии — при неудачной конвертации база восстановлению не подлежит
02
Несовпадение разрядности сервера 1С и клиента СУБД — сервер не видит базу данных
03
Конфликт портов при установке второй версии — служба агента не стартует
04
Забытая перепубликация веб-доступа — пользователи теряют работу через браузер
05
Обновление в разгар рабочего дня — активные сеансы обрываются, документы остаются непроведёнными
06
Необновлённые клиенты на рабочих местах — ошибки несовместимости версий у пользователей

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

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

FAQ: частые вопросы об обновлении платформы 1С на сервере

Можно ли обновить платформу, не останавливая работу пользователей?

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

Нужно ли обновлять конфигурацию вместе с платформой?

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

Что делать, если после обновления база требует конвертации?

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

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

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

Почему после обновления перестал работать веб-доступ к базе?

Модуль веб-расширения привязан к версии платформы. После обновления сервера публикацию на веб-сервере (IIS или Apache) нужно выполнить заново утилитой публикации от новой версии платформы, иначе веб-клиенты получат ошибку.

Как понять, что обновление прошло успешно?

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

Итог

Что важно запомнить

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