Как обновить сервер 1С с SQL-базой: полное руководство

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

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

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

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

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

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

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

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

Для SQL-базы резервную копию делают средствами самой СУБД, а не выгрузкой в dt. В Microsoft SQL Server это полная (Full) резервная копия через SQL Server Management Studio: правый клик по базе → «Задачи» → «Создать резервную копию». Для PostgreSQL используется утилита pg_dump. Такая копия сохраняет базу целиком и восстанавливается штатными средствами СУБД.

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

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

Обновление платформы на сервере 1С

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

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

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

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

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

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

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

После загрузки обновления выполните «Обновление конфигурации базы данных» (клавиша F7). На этом этапе платформа выполняет реструктуризацию таблиц в SQL-базе: на больших базах это самая долгая часть процесса, она может занимать часы. Прерывать реструктуризацию нельзя — это почти гарантированно приведёт к повреждению базы и восстановлению из копии.

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

Обновление клиентских рабочих мест

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

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

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

Способы обновления клиентов

Ручная установка

Подходит для 2–5 рабочих мест; при большем количестве отнимает много времени

Автообновление при подключении

Клиент сам скачивает нужную версию с сервера; требует настройки каталога дистрибутивов

Групповые политики / SCCM

Оптимально для доменной сети с десятками машин; требует подготовки пакета установки

Веб-клиент

Установка платформы не нужна вовсе; ограничение — не вся функциональность доступна в браузере

Проверка результата и откат при проблемах

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

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

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

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

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

Версия платформы в консоли кластера

Норма

Рабочие процессы на новой версии, база доступна

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

Процессы на старой версии или база недоступна

Вход пользователей

Норма

Клиенты подключаются без сообщения о несовпадении версий

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

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

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

Норма

Все обработчики завершены без ошибок

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

Обработчики зависли или завершились с ошибками

Журнал регистрации

Норма

Нет массовых ошибок после обновления

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

Повторяющиеся ошибки фоновых заданий или обменов

Типичные ошибки и как их избежать

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

Ещё одна группа проблем связана с правами: служба сервера 1С потеряла доступ к SQL Server после переустановки, у учётной записи обновления нет прав на изменение схемы базы, антивирус блокирует файлы платформы во время установки. Все эти моменты проверяются заранее и снимают большинство сбоев.

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

Можно ли обновлять платформу, не обновляя конфигурацию?

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

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

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

Чем отличается обновление на PostgreSQL от обновления на MS SQL?

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

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

Установка платформы — обычно 15–30 минут. Обновление конфигурации зависит от размера базы и количества пропущенных релизов: от получаса для небольшой базы до нескольких часов для крупной. Время реструктуризации заранее оцените на тестовой копии.

Что делать, если после обновления база стала работать медленно?

Чаще всего помогает обновление статистики и перестроение индексов в СУБД — после реструктуризации они устаревают. Также проверьте, что завершились все отложенные обработчики обновления, и убедитесь, что параметры СУБД (память, tempdb) соответствуют нагрузке.