Как обновить сервер 1С 8.3: полное руководство

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

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

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

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

Начните с определения текущей версии платформы. На сервере её видно в консоли кластера (консоль управления серверами 1С) в свойствах кластера, либо по пути установки — по умолчанию это C:\Program Files\1cv8\<номер версии> на Windows или /opt/1cv8/x86_64/<номер версии> на Linux. Заодно зафиксируйте список информационных баз, привязанных к кластеру.

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

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

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

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

Для клиент-серверных баз делайте копию средствами СУБД: полный backup базы в MS SQL Server, PostgreSQL или Oracle. Дополнительно полезно сделать выгрузку в dt через конфигуратор — это универсальный формат переноса, который пригодится при миграции на другой сервер.

Отдельно сохраните список информационных баз кластера. Самый надёжный способ — скопировать файл реестра кластера 1CV8Clst.lst из каталога srvinfo (обычно C:\Program Files\1cv8\srvinfo) или заскринить настройки каждой базы в консоли кластера: имя, сервер СУБД, имя базы, параметры. Если при обновлении что-то пойдёт не так с реестром кластера, вы восстановите привязки вручную за минуты.

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

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

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

На Linux установка выполняется из пакетов или скриптом setup-full из дистрибутива. После установки служба агента регистрируется через скрипт srv1cv8, запуск — стандартными средствами systemd или init. Убедитесь, что каталог srvinfo и права на него принадлежат пользователю, от имени которого работает агент.

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

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

Ключевой момент: новая версия платформы должна работать с тем же каталогом srvinfo, где хранится реестр кластера. Если установка шла в стандартные пути и служба запущена с теми же параметрами (порт агента 1540, порты кластера 1560–1591, рабочие процессы 1560+), кластер поднимется автоматически со всеми базами.

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

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

Обновление клиентов и веб-публикации

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

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

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

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

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

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

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

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

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

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

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

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

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