Администрирование · 12 мин
Как правильно обновить платформу 1С 8.3 на сервере
Подробная инструкция по обновлению платформы 1С 8.3 на сервере: подготовка, резервное копирование, установка новой версии, обновление информационных баз и проверка результата.
Обновление платформы 1С:Предприятие 8.3 на сервере — задача, которая напрямую влияет на стабильность работы всех информационных баз компании. Ошибка в процессе может привести к остановке учёта, невозможности запуска клиентов или несовместимости версий между сервером и рабочими местами. Поэтому обновление нужно планировать заранее и выполнять по строгому порядку действий.
Ключевой принцип: версия сервера 1С, версии клиентских приложений и требования конфигурации должны быть согласованы. Конфигурации (например, «1С:Бухгалтерия» или «1С:ERP») рассчитаны на определённую минимальную версию платформы, и обновлять платформу ниже или выше поддерживаемого диапазона нельзя без проверки совместимости.
Ниже разобран полный цикл работ: от проверки совместимости и резервного копирования до установки новой версии сервера, обновления баз и контроля результата. Материал ориентирован на администраторов, работающих с клиент-серверным вариантом 1С (сервер 1С + СУБД), но большинство шагов применимо и к небольшим развёртываниям.
Проверка совместимости версий перед обновлением
Первое действие — выяснить, какая версия платформы требуется. Обычно поводом для обновления служит выход нового релиза конфигурации, который требует более новую платформу, либо необходимость устранить известные ошибки текущей версии. Требования к платформе указаны в документации к релизу конфигурации и в файле поставки.
Проверьте текущую версию сервера: она отображается в консоли кластера серверов 1С, а также в окне «О программе» любого клиента. Сравните её с требуемой. Обратите внимание на полный номер версии — четыре группы цифр, например 8.3.22.xxxx. Конфигурации, как правило, допускают работу на версии не ниже указанной, но переход через несколько линеек (например, с 8.3.18 на 8.3.24) стоит выполнять с особой осторожностью и тестированием.
Отдельно проверьте разрядность и операционную систему сервера. Если планируется переход с 32-разрядной версии сервера на 64-разрядную, это фактически переустановка сервера, а не простое обновление, и требует отдельного планирования. Также убедитесь, что версия СУБД (MS SQL Server, PostgreSQL и другие) поддерживается новой версией платформы — перечень поддерживаемых СУБД приводится в документации 1С.
Подготовка: резервные копии и план отката
Резервное копирование — обязательный этап, пропускать который нельзя даже при «минорном» обновлении. Для клиент-серверных баз копию нужно делать средствами СУБД: полный бэкап базы данных через SQL Server Management Studio, pg_dump для PostgreSQL или штатные средства вашей СУБД. Выгрузка в .dt через конфигуратор — дополнительная мера, но не замена бэкапа СУБД для больших баз.
Помимо баз данных, зафиксируйте состояние самого сервера: состав установленных компонентов 1С, параметры кластера, список рабочих процессов и настройки службы агента сервера. Если сервер виртуальный — сделайте снапшот виртуальной машины перед началом работ. Это самый быстрый способ отката при неудаче.
Составьте план отката до начала работ: какую копию и в каком порядке восстанавливать, сколько времени займёт восстановление, кто отвечает за принятие решения об откате. Согласуйте с пользователями окно обслуживания — обновление выполняется при завершённых сеансах, поэтому выберите время минимальной нагрузки.
Установка новой версии платформы на сервер
Дистрибутив платформы загружается с портала 1С по действующей подписке. Для сервера нужен дистрибутив «Сервер 1С:Предприятия» соответствующей разрядности под вашу ОС (Windows или Linux). Установку выполняйте под учётной записью с правами администратора.
При установке на Windows запустите setup.exe и выберите компоненты: «Сервер 1С:Предприятия», «Администрирование сервера 1С:Предприятия» (консоль кластера), при необходимости — модули расширения веб-сервера. Новая версия ставится в отдельный каталог рядом со старой, удалять предыдущую версию сразу не требуется. Служба агента сервера новой версии регистрируется автоматически; если версии разных линеек работают одновременно, убедитесь, что у них разные диапазоны портов, чтобы избежать конфликта.
На Linux установка выполняется из пакетов дистрибутива с последующим запуском службы агента сервера (srv1cv83). После установки проверьте, что служба запущена, кластер доступен в консоли администрирования, а рабочие процессы стартуют без ошибок в журнале.
- 1Загрузите дистрибутив сервера нужной версии и разрядности с портала 1С
- 2Завершите сеансы пользователей и заблокируйте вход в базы
- 3Установите новую версию платформы рядом со старой, не удаляя предыдущую
- 4Проверьте запуск службы агента сервера и доступность кластера в консоли
- 5Обновите клиентские приложения на тестовом рабочем месте
- 6Обновите информационные базы и проверьте работу
- 7Только после успешной проверки разверните клиентов на все рабочие места
Обновление информационных баз и клиентов
После установки платформы базы в кластере продолжают ссылаться на старую версию. В консоли администрирования для каждой базы укажите новую версию платформы либо перенесите базу в кластер новой версии. Затем запустите конфигуратор под новой платформой: при первом открытии может потребоваться обновление версии конфигурации базы данных — выполните его, предварительно убедившись, что все пользователи отключены и фоновые задания заблокированы.
Обновление структуры базы данных на больших базах может занять продолжительное время — это нормально, прерывать процесс нельзя. Если база работает в режиме совместимости, платформа сама подскажет необходимость его изменения; менять режим совместимости следует осознанно, согласно требованиям конфигурации.
Клиентские приложения обновляются на каждом рабочем месте. Варианты: ручная установка из дистрибутива, развёртывание через групповые политики домена или автоматическое обновление тонкого клиента при подключении через веб-сервер (если публикация настроена соответствующим образом). Версии клиента и сервера должны совпадать, иначе подключение будет отклонено с ошибкой несовпадения версий.
Способы обновления клиентов
Подходит при небольшом числе рабочих мест. Ограничение: требует обхода каждого компьютера и прав администратора на нём.
Подходит для доменной сети с десятками ПК. Требует подготовки пакета установки и тестирования на пилотной группе.
Удобно при публикации баз через веб: тонкий клиент скачивает нужную версию автоматически. Ограничение: работает только для подключений через веб-сервер.
Проверка результата после обновления
Формально завершённая установка не означает успешное обновление. Проверку начните с технологического журнала и журнала регистрации: не должно быть ошибок запуска рабочих процессов, фоновых заданий и подключений к СУБД. Затем выполните контрольные операции в самой базе.
Минимальный набор проверок: вход под тестовой учётной записью с типовыми правами, открытие и проведение документа, формирование ключевых отчётов, запуск регламентных заданий вручную, проверка обменов данными с другими системами, если они настроены. Особое внимание — интеграциям: внешние компоненты, COM-соединения и веб-сервисы чувствительны к смене версии платформы и разрядности сервера.
Тестирование обновления заранее на копии базы — лучшая практика, особенно для крупных внедрений. Разверните копию из резервной копии на тестовом сервере, прогоните весь цикл обновления и зафиксируйте время выполнения: это даст реалистичную оценку длительности окна обслуживания на боевом сервере.
Как проверить результат
Служба работает, кластер виден в консоли, рабочие процессы активны
Служба не стартует, в журнале ошибки портов или лицензий
Клиент входит без сообщений о несовпадении версий
Ошибка несовпадения версий клиента и сервера
Задания выполняются по расписанию, в журнале регистрации нет ошибок
Задания не запускаются или завершаются с ошибками
Документы проводятся, отчёты формируются за привычное время
Ошибки при проведении, резкое замедление отчётов
Типичные ошибки и как их избежать
Самая частая проблема — рассинхронизация версий клиента и сервера. Пользователь обновил клиент раньше времени или, наоборот, не обновил — и получает ошибку подключения. Решение: централизованное развёртывание клиентов и запрет самостоятельной установки платформы пользователями.
Вторая группа ошибок связана с лицензиями. Серверные и клиентские лицензии должны быть доступны после обновления; при смене разрядности сервера или переносе на другое оборудование может потребоваться переактивация программных лицензий. Проверьте наличие активных лицензий и пин-кодов до начала работ.
Третья типичная ситуация — обновление «вживую» без блокировки сеансов. Фоновые задания и активные пользователи во время обновления структуры базы могут привести к ошибкам и незавершённым транзакциям. Всегда используйте блокировку сеансов через консоль кластера или функциональность конфигурации.
Дополнительные сценарии и ограничения
Переход с 32-разрядной версии на 64-разрядную
Это не обновление, а миграция: устанавливается 64-разрядный сервер, кластер пересоздаётся, базы переносятся. Учтите, что внешние компоненты и COM-объекты, рассчитанные на 32-разрядную среду, могут потребовать замены или настройки. Планируйте такой переход отдельным проектом с полным тестированием.
Обновление при работе через веб-сервер
Если базы опубликованы на веб-сервере (IIS или Apache), после смены версии платформы публикации нужно обновить: перепубликуйте базы, чтобы модули расширения веб-сервера соответствовали новой версии. Иначе веб-клиенты и тонкие клиенты через веб получат ошибки подключения.
Когда обновление лучше отложить
Не планируйте обновление в периоды отчётности, инвентаризаций и закрытия периода. Если текущая версия работает стабильно, а новый релиз конфигурации не требует повышения платформы, разумно дождаться накопления исправлений и обновиться в спокойное окно. Обновление «ради новой версии» без функциональной необходимости добавляет риски без выгоды.
Держите на сервере минимум две последние рабочие версии платформы. Если после обновления всплывёт ошибка новой версии, вы сможете быстро вернуть базы на предыдущую без переустановки, потеряв минимум времени.
Часто задаваемые вопросы
Можно ли обновлять платформу, пока пользователи работают в базе?
Установить новую версию платформы на сервер можно и при работающих пользователях — она ставится в отдельный каталог и не мешает текущей. Но переключение баз на новую версию и обновление структуры базы данных выполняются только при завершённых сеансах и заблокированных фоновых заданиях.
Что делать, если после обновления клиенты не подключаются с ошибкой несовпадения версий?
Ошибка означает, что версия клиентского приложения отличается от версии сервера. Обновите платформу на рабочем месте до той же версии. Если рабочих мест много, используйте групповые политики или автоматическое обновление тонкого клиента через веб-сервер.
Нужно ли обновлять конфигурацию вместе с платформой?
Не обязательно, но нужно проверить совместимость: текущая конфигурация должна поддерживать новую версию платформы. Чаще всего платформу обновляют именно потому, что этого требует новый релиз конфигурации, поэтому оба обновления планируют совместно в одно окно обслуживания.
Достаточно ли выгрузки базы в .dt для отката?
Для небольших файловых баз — как правило, да. Для клиент-серверных баз выгрузка в .dt — медленный и не всегда надёжный способ восстановления больших объёмов; основной копией должен быть бэкап средствами СУБД, а .dt использовать как дополнительную страховку.
Как откатиться, если новая версия работает с ошибками?
Если старая версия платформы не удалена, переведите базы обратно на неё в консоли кластера и восстановите клиенты прежней версии. Если структура базы уже была обновлена и откат невозможен, восстановите базу из резервной копии СУБД, сделанной до обновления.
Что важно запомнить
Обновление платформы 1С 8.3 на сервере — это проверка совместимости, обязательная резервная копия, установка новой версии рядом со старой, обновление баз и клиентов, а затем контрольная проверка. Тестовый прогон на копии и готовый план отката превращают рискованную операцию в управляемую процедуру.