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

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

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

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

Что проверить перед началом обновления

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

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

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

Резервная копия: почему выгрузка .dt не заменяет бэкап СУБД

Для серверной базы основной способ резервного копирования — штатные средства СУБД: полный backup в MS SQL Server или pg_dump для PostgreSQL. Такой бэкап создаётся быстро, согласованно и гарантированно восстанавливается в исходное состояние. Выгрузка в файл .dt через Конфигуратор для серверной базы — вспомогательный инструмент: она идёт долго на больших базах и не всегда корректно восстанавливается между разными версиями платформы.

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

BACKUP DATABASE [MyBase1C] TO DISK = 'D:\Backups\MyBase1C_before_update.bak' WITH COMPRESSION, CHECKSUM;

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

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

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

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

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

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

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

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

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

Учтите тонкость: при первом запуске базы на новой версии платформы может выполняться конвертация, после которой база перестанет открываться на старой версии. Это ещё один аргумент в пользу проверенной резервной копии.

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

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

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

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

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

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

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

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

Самая частая проблема — попытка обновления без монопольного доступа: процесс обрывается сообщением о конфликте блокировок. Решение — проверить консоль кластера и завершить «невидимые» сеансы, включая фоновые задания и сеансы веб-сервисов.

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

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

FAQ