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

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

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

Перед началом убедитесь, что у вас есть: права администратора кластера серверов 1С, доступ к консоли кластера, учётная запись с полными правами в самой базе, доступ к серверу СУБД для создания резервной копии и актуальный дистрибутив обновления (файл .cfu или полный .cf). Также проверьте, что версия платформы 1С соответствует минимальным требованиям нового релиза конфигурации — это указано в файле поставки или в описании релиза на портале 1С.

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

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

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

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

Резервное копирование серверной базы

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

Для MS SQL выполните полное резервное копирование через SQL Server Management Studio: правый клик по базе — «Задачи — Создать резервную копию», тип — «Полная». Для PostgreSQL используйте pg_dump или pg_basebackup. Сохраните копию на отдельный диск или сетевое хранилище, а не на тот же том, где лежат файлы базы.

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

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

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

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

Чтобы пользователи не заходили в базу во время обновления, установите блокировку сеансов. В консоли кластера: свойства информационной базы — «Блокировка сеансов» — установите дату начала, сообщение для пользователей и код разрешения доступа. Код разрешения позволит вам самому войти в базу, несмотря на блокировку: при запуске укажите параметр /UC<код>.

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

Установка шаблона и обновление конфигурации

Запустите установщик обновления (setup.exe из дистрибутива релиза) на компьютере, с которого будете работать в конфигураторе. Шаблон установится в каталог шаблонов (по умолчанию в профиле пользователя, папка tmplts). Если обновление ставится на сервере терминалов, убедитесь, что шаблон доступен той учётной записи, под которой запускается конфигуратор.

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

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

1. 1
   Создать полную резервную копию базы средствами СУБД
2. 2
   Проверить совместимость версии платформы и нового релиза
3. 3
   Завершить сеансы и установить блокировку сеансов в консоли кластера
4. 4
   Установить шаблон обновления на рабочее место администратора
5. 5
   В конфигураторе: Конфигурация — Поддержка — Обновить конфигурацию
6. 6
   Выполнить «Обновление конфигурации базы данных» (F7) с принятием изменений
7. 7
   Запустить базу в режиме Предприятие под полными правами и дождаться обработчиков обновления
8. 8
   Проверить версию, работу ключевых функций и снять блокировку сеансов

Обновление конфигурации базы данных и запуск обработчиков

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

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

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

Проверка результата и снятие блокировки

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

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

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

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

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

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

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

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