Как обновить 1С на сервере Linux

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

На Linux чаще всего встречается связка: сервер 1С:Предприятия (deb- или rpm-пакеты), СУБД PostgreSQL и клиентские подключения через веб-сервер Apache или тонкий клиент. Каждый из этих компонентов влияет на процедуру обновления. Ниже разобран полный цикл: от подготовки и резервного копирования до проверки работоспособности после обновления.

Главный принцип — обновление всегда делается на заблокированной базе с готовой резервной копией. Любое отклонение от этого правила превращает штатную процедуру в аварийное восстановление данных.

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

До скачивания дистрибутива определите текущие версии платформы и конфигурации. Версию платформы на сервере показывает команда /opt/1cv8/current/*/bin/rac --version или просмотр установленных пакетов: dpkg -l | grep 1c для Debian/Ubuntu и rpm -qa | grep 1c для RHEL-подобных систем. Версию конфигурации видно в конфигураторе в разделе «О программе» либо в свойствах базы в консоли кластера.

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

Убедитесь в наличии свободного места на диске: дистрибутив платформы занимает сотни мегабайт, а обновление конфигурации может временно увеличить размер базы и журналов транзакций PostgreSQL. Также проверьте, что у вас есть действующий договор ИТС или иной легальный доступ к дистрибутивам обновлений.

Резервное копирование базы

Резервная копия — единственный способ откатить неудачное обновление. Для клиент-серверной базы на PostgreSQL правильный способ — средствами СУБД, а не выгрузка .dt. Выгрузка .dt из конфигуратора занимает много времени на больших базах и не является полноценной копией, хотя как дополнительная страховка не помешает.

Стандартная команда для PostgreSQL:

Блокировка базы и завершение сеансов

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

Пример команды через rac:

Если на сервере должны сосуществовать несколько версий платформы, устанавливайте их параллельно — установщик 1С кладёт каждую версию в отдельный каталог вида /opt/1cv8/x86_64/8.3.xx.xxxx. В этом случае переключите службу на новый каталог, отредактировав unit-файл systemd или переменные в скрипте запуска агента.

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

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

Конфигурацию обновляют после платформы. На сервере без графической оболочки удобнее всего пакетный режим конфигуратора, запущенный либо на самом сервере (если установлены графические библиотеки), либо на администраторской машине с доступом к кластеру.

Типовой сценарий: «Конфигурация → Поддержка → Обновить конфигурацию», выбор файла обновления (.cfu) из дистрибутива релиза. В пакетном режиме команда выглядит так:

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

Откат и частые проблемы

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

Типичные проблемы и их признаки: служба агента не стартует после обновления (смотрите journalctl -u <служба> — чаще всего конфликт портов или неверный путь в unit-файле), ошибка лицензии (проверьте файлы лицензий в /var/1C/licenses), ошибки СУБД при реструктуризации (нехватка места в tablespace или слишком низкий maintenance_work_mem).

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

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

Можно ли обновлять платформу без остановки работы пользователей?

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

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

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

Что делать, если обновление конфигурации зависло на реструктуризации?

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

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

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

Нужно ли обновлять PostgreSQL вместе с платформой 1С?

Нет, это независимые компоненты. PostgreSQL обновляют по своим причинам: окончание поддержки версии, требования безопасности. Главное — использовать сборку PostgreSQL, совместимую с 1С, и проверять требования конкретной версии платформы к СУБД.

Можно ли автоматизировать обновление скриптами?

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