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

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

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

Ниже — практический порядок действий для Windows- и Linux-установки, проверки после обновления и типичные ошибки. Инструкция подходит для серверов с одним кластером и стандартными настройками; для сложных схем с несколькими кластерами и балансировкой порядок тот же, но действия повторяются на каждом узле.

Что нужно проверить перед обновлением

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

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

Третье — требования к операционной системе и СУБД. Новые версии платформы могут прекращать поддержку старых версий Windows Server, Linux-дистрибутивов или СУБД. Актуальный список поддерживаемых сред есть в документации к конкретному релизу платформы. Также убедитесь, что на диске достаточно свободного места для установки и что у вас есть дистрибутив и действующая лицензия (для сервера — программная лицензия или аппаратный ключ HASP).

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

Перед любыми действиями с сервером сделайте полную резервную копию информационных баз. Надёжнее всего — штатными средствами СУБД: для MS SQL это full backup базы, для PostgreSQL — pg_dump или физическая копия кластера. Копия средствами СУБД гарантирует целостность и позволяет быстро откатиться.

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

Отдельно скопируйте каталоги с настройками сервера: на Windows это обычно каталог srvinfo внутри каталога агента сервера, на Linux — аналогичный каталог кластера. Там хранится реестр кластера, список баз, настройки рабочих процессов и менеджеров. Если после обновления агент «потеряет» базы, восстановить их из этого каталога проще, чем регистрировать заново.

Подготовка сервера к установке

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

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

Проверьте, под какой учётной записью работает служба агента сервера (по умолчанию на Windows — USR1CV8, на Linux — usr1cv8). У этой учётной записи должны остаться права на каталоги сервера и доступ к СУБД, если используется аутентификация ОС. Установщик платформы требует прав администратора на сервере.

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

Обновление на Windows

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

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

Обновление на Linux

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

sudo systemctl stop srv1cv8
sudo rpm -Uvh 1c-enterprise-<em>.rpm   # или: sudo dpkg -i 1c-enterprise-</em>.deb
sudo systemctl start srv1cv8
sudo systemctl status srv1cv8

После установки убедитесь, что каталог кластера (srvinfo) остался на месте и доступен пользователю, под которым работает агент. Если права сбросились, верните владельца: chown -R usr1cv8:grp1cv8 на каталог данных кластера.

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

Настройка кластера и регистрация баз после обновления

В большинстве случаев после установки новой версии агент подхватывает существующий каталог srvinfo, и все базы остаются зарегистрированными. Откройте консоль администрирования (она ставится вместе с компонентой «Администрирование сервера»), подключитесь к серверу и проверьте, что кластер виден, а в нём — все информационные базы.

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

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

Проверка работоспособности после обновления

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

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

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

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

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

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

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

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

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

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

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

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