Как обновить сервер 1С:Предприятия без потери данных

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

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

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

Проверьте совместимость версий перед обновлением

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

Узнать текущую версию сервера можно в консоли администрирования серверов 1С:Предприятия (оснастка «Центральные серверы» → свойства кластера) или в свойствах службы «Агент сервера 1С:Предприятия» — путь к исполняемому файлу ragent.exe содержит номер версии. На Linux версию показывает путь каталога установки, например /opt/1cv8/x86_64/8.3.22.1750.

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

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

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

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

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

Установите новую платформу на сервер

Установка на Windows

Запустите setup.exe из дистрибутива платформы от имени администратора. Установщик предложит выбрать компоненты: для сервера обязательны «Сервер 1С:Предприятия» и «Администрирование сервера 1С:Предприятия». По умолчанию новая версия ставится в отдельный каталог с номером версии внутри Program Files — старая версия при этом не удаляется, что позволяет быстро откатиться.

На этапе установки службы агента сервера укажите учётную запись, под которой работает служба (обычно USR1CV8), и её пароль. Если обновление ставится «рядом» со старой версией, служба новой версии регистрируется с теми же портами только после остановки старой — иначе возникнет конфликт портов 1540–1541 и 1560–1591.

Установка на Linux

На Linux платформа распространяется в виде пакетов deb или rpm. Установка выполняется пакетным менеджером, после чего служба агента сервера запускается через systemd или скрипт srv1cv8. Пример для deb-пакетов:

sudo dpkg -i *.deb
sudo systemctl start srv1cv8-8.3.22.1750@default
sudo systemctl status srv1cv8-8.3.22.1750@default

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

Перерегистрируйте службу и проверьте кластер

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

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

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

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

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

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

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

Типичные ошибки и как их избежать

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

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

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

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

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

Частые вопросы