Как обновить конфигурацию 1С на сервере

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

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

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

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

Первое действие — убедиться, что у вас есть актуальная резервная копия базы. На сервере копию делают средствами СУБД: для MS SQL Server — через SQL Server Management Studio (полный backup базы), для PostgreSQL — через pg_dump. Выгрузка в .dt из конфигуратора допустима как дополнительная копия, но на больших базах она медленная и не заменяет штатный бэкап СУБД.

Далее проверьте, что установленная платформа 1С совместима с новой версией конфигурации. В описании релиза на портале 1С указана минимальная требуемая версия платформы. Если текущая платформа старше — сначала обновляется платформа на сервере, и только потом конфигурация.

Также заранее скачайте дистрибутив обновления с портала portal.1c.ru (требуется действующая подписка ИТС) и установите шаблон обновления на компьютер администратора. Проверьте, что ваш релиз входит в список поддерживаемых для этого обновления — если база пропустила несколько версий, обновлять придётся последовательно.

Как завершить сеансы пользователей на сервере

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

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

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

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

Обновление типовой конфигурации через конфигуратор

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

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

Дождитесь полного завершения реструктуризации. Прерывать процесс (закрывать конфигуратор, перезагружать сервер) категорически нельзя — это почти гарантированно приводит к повреждению структуры базы и восстановлению из копии.

Обновление доработанной конфигурации

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

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

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

Обновление через cf-файл и сравнение конфигураций

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

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

Сравнение способов обновления

Обновление через поддержку

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

Загрузка из cf-файла

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

Сравнение и объединение

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

Проверка результата и запуск пользователей

После реструктуризации запустите базу в режиме предприятия с кодом разрешения. Типовые конфигурации при первом запуске выполняют отложенные обработчики обновления — перенос данных, заполнение новых реквизитов. Дождитесь их завершения: ход выполнения виден в разделе «Администрирование — Результаты обновления программы».

Проверьте ключевые сценарии: проведение основных документов, формирование регламентированных отчётов, работу обменов с другими системами. Убедитесь, что номер версии в разделе «О программе» соответствует установленному релизу.

Только после успешной проверки снимите блокировку сеансов в консоли кластера и разрешите регламентные задания. Сообщите пользователям, что работа возобновлена.

Контрольные точки

Как проверить результат

Версия конфигурации

Норма

В разделе «О программе» отображается новый релиз

Тревожный признак

Версия старая или обновление завершилось с ошибкой в журнале

Отложенные обработчики

Норма

Все обработчики обновления выполнены успешно

Тревожный признак

Есть обработчики со статусом «Ошибка» — их нужно перезапустить после исправления причины

Проведение документов

Норма

Типовые документы создаются и проводятся без ошибок

Тревожный признак

Ошибки при проведении — вероятно, не завершены обработчики или есть конфликт доработок

Типичные ошибки при обновлении на сервере

Самая частая проблема — попытка обновить базу через несколько пропущенных релизов одним шагом. Шаблоны обновления рассчитаны на конкретные исходные версии; если ваш релиз не входит в список, обновляйтесь последовательно через промежуточные версии.

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

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

Можно ли обновить конфигурацию через веб-интерфейс из режима предприятия?

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

Сколько времени занимает обновление серверной базы?

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

Что делать, если обновление завершилось с ошибкой?

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

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

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

Как обновить базу, которая пропустила много релизов?

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