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

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

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

Ниже разобран порядок обновления для типовой связки «сервер 1С + СУБД (MS SQL или PostgreSQL)», а также отличия для файлового варианта и частые ошибки, из-за которых базы перестают открываться.

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

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

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

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

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

Резервная копия делается двумя независимыми способами. Первый — средствами СУБД: полный backup базы данных через SQL Server Management Studio или pg_dump для PostgreSQL. Второй — выгрузка информационной базы в файл .dt через конфигуратор. Копия в .dt занимает больше времени, но позволяет поднять базу даже на другом сервере и другой СУБД.

Дополнительно сохраните каталоги сервера 1С: папку srvinfo (в ней хранится реестр кластера, настройки рабочих процессов и список баз) и каталог установки платформы, если в него вносились изменения (например, файлы nethasp.ini или настройки лицензирования). Скопируйте данные на отдельный носитель или сетевое хранилище — копия на том же диске не спасает при отказе диска.

Завершение сеансов и остановка служб

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

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

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

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

Дистрибутив платформы скачивается с портала 1С по действующей подписке. Установщик запускается от имени администратора. На сервере выбираются компоненты: «Сервер 1С:Предприятия», «Администрирование сервера», при необходимости — «Сервер хранилища конфигураций» и модули расширения веб-сервера, если публикация баз идёт через IIS или Apache.

Установка возможна двумя способами. Первый — новая версия ставится рядом со старой (в отдельный каталог, например 8.3.22 рядом с 8.3.20), а служба агента перерегистрируется на новую версию. Это предпочтительный вариант: откат сводится к обратной перерегистрации службы. Второй — удаление старой версии и установка новой; он проще, но откат требует повторной установки старого дистрибутива.

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

"C:\Program Files\1cv8\8.3.22.XXXX\bin\ragent.exe" -instsrvc -usr .\USR1CV8 -pwd <strong><em><em></strong></em></em> -d "C:\Program Files\1cv8\srvinfo" -port 1540 -regport 1541 -range 1560:1591

Запуск и проверка работоспособности

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

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

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

Откат и особые сценарии

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

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

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

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