Администрирование · 12 мин
Как обновить сервер 1С на Linux без простоя и потери данных
Пошаговое обновление сервера 1С:Предприятие на Linux: подготовка, резервные копии, установка платформы, проверка служб и типичные ошибки администраторов.
Обновление сервера 1С:Предприятие на Linux — рутинная, но ответственная операция: от неё зависит стабильность работы всех пользователей, подключённых к кластеру. В отличие от Windows-установщика, на Linux обновление выполняется через пакеты дистрибутива или ручное развёртывание архива, а значит, администратору нужно контролировать зависимости, права доступа и состояние служб.
Главная сложность — согласование версий. Платформа сервера, клиентские приложения и сами конфигурации должны быть совместимы: обновив только сервер, можно получить массовые ошибки подключения у пользователей со старыми клиентами. Поэтому обновление планируют как единый процесс: сервер, клиенты и, при необходимости, обновление конфигурации базы данных.
Ниже — практический порядок действий для типового развёртывания 1С на Linux (RPM- или DEB-дистрибутивы) с сервером баз данных PostgreSQL или MS SQL. Команды приведены для распространённых сценариев, но пути и имена пакетов могут отличаться в зависимости от версии платформы и дистрибутива.
Подготовка: что проверить до начала обновления
Первый шаг — определить текущую версию платформы и целевую версию. Текущую версию агента сервера можно посмотреть через консоль кластера или командой просмотра установленных пакетов. Целевую версию выбирают исходя из требований конфигурации: у каждого релиза 1С-конфигурации указана минимально необходимая версия платформы, и её нужно соблюдать.
Проверьте совместимость по трём направлениям: сервер и клиенты (желательно одна версия платформы), платформа и конфигурация (требования указаны в документации к релизу конфигурации), платформа и операционная система (поддерживаемые дистрибутивы перечислены в системных требованиях 1С). Несовпадение по любому из пунктов — повод перенести обновление и сначала устранить разрыв.
Убедитесь, что у вас есть: дистрибутив новой версии платформы для нужной архитектуры, права root или sudo на сервере, доступ к серверу СУБД и достаточное свободное место на диске — как минимум под резервные копии и временные файлы установщика.
Совместимость конфигурации и клиентов с новой версией
Место под резервные копии баз и файлы установщика
План отключения пользователей и фоновых заданий
Рабочая процедура возврата к прежней версии
Резервное копирование перед обновлением
Резервная копия — обязательное условие, а не рекомендация. Обновление платформы само по себе не изменяет данные, но часто сопровождается обновлением конфигурации, которое выполняет реструктуризацию базы. Если процесс прервётся или завершится ошибкой, восстановиться можно только из копии.
Делайте копию средствами СУБД: для PostgreSQL это pg_dump, для MS SQL — штатный backup. Выгрузка базы из конфигуратора в файл .dt допустима как дополнительная мера, но для больших баз она медленная и не заменяет копию на уровне СУБД. Также сохраните список баз кластера и настройки сервера — пригодится при восстановлении.
sudo -u postgres pg_dump -Fc -f /backup/infobase_before_update.dump infobaseПроверьте, что копия реально создалась и имеет ненулевой размер. Идеальный вариант — периодически тестировать восстановление на отдельной машине: копия, которую никогда не разворачивали, нельзя считать надёжной.
Остановка сеансов и блокировка работы пользователей
Перед установкой новой версии все пользователи должны завершить работу. Активные сеансы во время обновления конфигурации недопустимы, а во время обновления платформы создают риск рассинхронизации: часть процессов будет работать на старой версии, часть — на новой.
Порядок действий: заранее уведомите пользователей о технологическом окне, через консоль кластера установите блокировку начала сеансов для информационных баз, дождитесь завершения текущих сеансов или завершите их принудительно. Не забудьте про регламентные и фоновые задания — их тоже нужно остановить, иначе задание может запуститься в середине обновления.
Если на сервере работают интеграционные сервисы (обмены с сайтом, веб-сервисы, план обмена с другими базами), отключите и их: внешние системы могут создавать подключения, которые помешают монопольному режиму.
- 1Уведомить пользователей и согласовать время простоя
- 2Сделать резервную копию базы средствами СУБД
- 3Установить блокировку сеансов в консоли кластера
- 4Остановить регламентные и фоновые задания
- 5Завершить оставшиеся сеансы и отключить интеграции
- 6Убедиться, что активных подключений не осталось
Установка новой версии платформы на Linux
Дистрибутив 1С для Linux поставляется в виде набора пакетов: сервер, дополнительные компоненты, тонкий и толстый клиенты, модули расширения веб-сервера. Для обновления сервера достаточно пакетов сервера, но если на этой же машине стоят клиенты или веб-компоненты, их версии тоже нужно привести к новой.
Для DEB-систем (Debian, Ubuntu, Astra Linux) установка выполняется через dpkg или apt, для RPM-систем (Red Hat, CentOS, ALT Linux, РЕД ОС) — через rpm или yum/dnf. Пакеты новой версии ставятся поверх или рядом со старой — в зависимости от того, как организована установка: каталоги разных версий платформы традиционно разделяются по номеру версии, что упрощает откат.
sudo dpkg -i 1c-enterprise-<em>-server_</em>.deb 1c-enterprise-<em>-server-nls_</em>.deb 1c-enterprise-<em>-common_</em>.debПосле установки убедитесь, что файлы платформы легли в каталог новой версии (обычно внутри /opt с подкаталогом по номеру версии), а права и владелец файлов корректны — служба агента сервера работает от выделенного пользователя, и у неё должен быть доступ к исполняемым файлам и рабочему каталогу кластера.
Перезапуск служб и обновление конфигурации базы
После установки пакетов перезапустите службу агента сервера 1С. Имя службы зависит от способа установки и версии, обычно это что-то вроде srv1cv8 с номером версии. Перезапуск выполняется через systemctl. Если агент запускается скриптом с указанием каталога конкретной версии — проверьте, что скрипт или unit-файл systemd указывает на новую версию.
sudo systemctl restart srv1cv8-8.3.XX-XXXX && sudo systemctl status srv1cv8-8.3.XX-XXXXДалее — обновление конфигурации базы данных, если оно требуется новым релизом конфигурации. Это делается через конфигуратор в монопольном режиме или пакетным запуском конфигуратора с параметрами обновления. Реструктуризация больших баз может занимать значительное время — это нормально, прерывать процесс нельзя.
Если используется веб-доступ (тонкий клиент через браузер, веб-сервисы), после смены версии платформы нужно заново опубликовать базы на веб-сервере: модуль расширения веб-сервера привязан к версии платформы, и старый модуль с новой платформой работать не будет.
Частая ситуация: пакеты установлены, служба перезапущена, а кластер поднимается на старой версии. Причина почти всегда в том, что unit-файл systemd или стартовый скрипт жёстко указывает путь к каталогу прежней версии. Проверяйте фактический путь к исполняемому файлу агента через systemctl cat и ps aux, а не только наличие новых пакетов в системе.
Проверка результата и возврат пользователей
Проверку начинайте с инфраструктурного уровня: служба агента активна, процессы кластера (ragent, rmngr, rphost) запущены и работают на новой версии, в консоли кластера видны сервер и информационные базы. Затем — тестовый вход в каждую базу: запуск конфигуратора или клиента, открытие ключевых форм, выполнение типовых операций.
Отдельно проверьте регламентные задания (включите их и убедитесь, что выполняются без ошибок), работу веб-публикаций и интеграционных обменов. Только после этого снимайте блокировку сеансов и сообщайте пользователям о возобновлении работы. Клиентские машины при этом должны получить новую версию платформы — через групповое развёртывание или автоматическое обновление тонкого клиента при подключении.
Как проверить результат
systemctl показывает active (running), версия процесса новая
Служба падает или запущена старая версия
Сервер и базы видны, рабочие процессы активны
Кластер недоступен или список баз пуст
Клиент подключается, формы открываются без ошибок
Ошибка несовпадения версий или недоступности сервера
Задания выполняются по расписанию без ошибок
Задания не стартуют или завершаются с ошибкой
В течение первых дней после обновления наблюдайте за журналом регистрации и системным журналом Linux: часть проблем (например, нехватка памяти при новых настройках рабочих процессов) проявляется только под реальной нагрузкой.
Откат и типичные ошибки
Откат платформы при сохранённой старой версии несложен: остановить службу, вернуть запуск на каталог прежней версии, запустить службу. Но если была выполнена реструктуризация базы под новую конфигурацию — откат конфигурации возможен только восстановлением базы из резервной копии. Именно поэтому копия до обновления критична.
Ещё одна группа проблем связана с зависимостями ОС: новая версия платформы может требовать более свежие системные библиотеки. Если при установке пакета возникают ошибки зависимостей — не форсируйте установку с игнорированием зависимостей, а сначала обновите систему в рамках поддерживаемой конфигурации.
Как выбрать действие
FAQ: частые вопросы об обновлении сервера 1С на Linux
Можно ли обновлять сервер 1С без остановки работы пользователей?
Нет. Смена версии платформы требует перезапуска служб кластера, а обновление конфигурации — монопольного доступа к базе. Операцию планируют на нерабочее время: вечер, ночь или выходные, с предварительным уведомлением пользователей.
Нужно ли обновлять сервер СУБД вместе с платформой 1С?
Не обязательно, но версия СУБД должна входить в список поддерживаемых для новой версии платформы. Если текущая версия PostgreSQL или MS SQL устарела относительно требований, обновление СУБД планируют отдельным этапом — со своей резервной копией и тестированием.
Как узнать, какая версия платформы сейчас работает на сервере?
Через консоль администрирования кластера в свойствах сервера, либо на самом сервере — по пути запущенного процесса ragent (каталог содержит номер версии) или через список установленных пакетов пакетного менеджера.
Что делать, если после обновления база требует реструктуризации, но она идёт слишком долго?
Для больших баз длительная реструктуризация — норма, процесс может занимать часы. Прерывать его нельзя. На будущее: сначала прогоните обновление на тестовой копии базы, чтобы оценить реальную длительность и заложить достаточное технологическое окно.
Можно ли держать на одном Linux-сервере несколько версий платформы 1С?
Да, версии устанавливаются в раздельные каталоги и могут сосуществовать. Для одновременной работы нескольких версий настраивают отдельные службы агентов с разными портами. Чаще этой возможностью пользуются для плавной миграции баз и быстрого отката.
Обновление платформы и обновление конфигурации — это одно и то же?
Нет. Платформа — это исполняемая среда 1С (сервер и клиенты), конфигурация — прикладное решение внутри базы. Они обновляются независимо, но связаны требованиями совместимости: новый релиз конфигурации может требовать минимальную версию платформы.
Что важно запомнить
Обновление сервера 1С на Linux безопасно только при соблюдении последовательности: проверенная резервная копия, блокировка сеансов, установка пакетов новой версии, корректный перезапуск служб, перепубликация веб-доступа и тестирование до возврата пользователей. Старую версию платформы и копию базы сохраняйте до подтверждения стабильной работы — это ваш единственный путь отката.