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

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

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

Ниже разобран полный цикл работ: от подготовки и резервного копирования до проверки результата и отката при неудаче. Материал ориентирован на администраторов, работающих с сервером 1С:Предприятия 8.3 под Windows или Linux с СУБД MS SQL Server, PostgreSQL или аналогом.

Что нужно проверить до начала обновления

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

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

Убедитесь, что у вас есть действующий договор информационно-технологического сопровождения (ИТС) или иной легальный доступ к дистрибутивам: обновления платформы скачиваются с портала portal.1c.ru. Также проверьте свободное место на диске сервера — для установки и временных файлов реструктуризации может потребоваться объём, сопоставимый с размером самой базы.

Резервное копирование — обязательный этап

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

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

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

Остановка работы пользователей и служб

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

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

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

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

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

Запустите установщик дистрибутива платформы на сервере от имени администратора. На Windows выберите компоненты «Сервер 1С:Предприятия» и нужную разрядность — для 64-разрядного сервера устанавливайте 64-битную версию. Установщик добавит новую версию рядом со старой: разные версии платформы на одном сервере сосуществуют в отдельных каталогах.

После установки служба агента сервера 1С должна быть перерегистрирована или перезапущена с новой версией. Если служба запускалась как служба Windows, установщик обычно предлагает перерегистрировать её; при ручном управлении используйте утилиту ragent с параметрами регистрации службы. На Linux служба управляется через systemd — остановите юнит, установите пакеты новой версии, запустите юнит снова.

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

sc stop "1C:Enterprise 8.3 Server Agent" && sc start "1C:Enterprise 8.3 Server Agent"

Обновление конфигурации и реструктуризация базы

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

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

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

Проверка результата и откат при неудаче

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

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

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

Типичные ошибки при обновлении сервера 1С

Большинство проблем при обновлении связаны не с самой платформой, а с нарушением порядка подготовки. Характерные ошибки: обновление без резервной копии, незавершённые сеансы пользователей во время реструктуризации, забытые регламентные задания и несовпадение версий клиентов и сервера.

Отдельная группа рисков — разрядность и компоненты. Установка 32-битного сервера вместо 64-битного ограничивает доступную память рабочих процессов, а отсутствие нужных компонентов (например, сервера хранилища или Web-сервисов) ломает смежные механизмы. Перед установкой сверьте список компонентов с текущей конфигурацией.

Часто задаваемые вопросы