← На главную

При администрировании информационных баз 1С часто возникает вопрос: обязательно ли последовательно накатывать все промежуточные версии платформы (например, переходить с ветки 8.3.8 на 8.3.9, а затем на 8.3.10) или можно сразу установить актуальный релиз? Разберем подробно механику обновления платформы, правила совместимости конфигураций и правильную процедуру отката в случае возникновения непредвиденных ошибок.

Возможность пропуска промежуточных версий платформы

В отличие от прикладных конфигураций (таких как 1С:Бухгалтерия или 1С:Зарплата и управление персоналом), где строгая последовательность обновлений продиктована обработчиками обновления данных, сама технологическая платформа 1С:Предприятие не требует последовательной цепочки установки. Переход можно выполнять сразу через несколько релизов и даже через несколько промежуточных веток (например, напрямую с 8.3.8 на 8.3.10).

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

Почему возврат на старую платформу вызывает сложности

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

1. Изменение структуры таблиц базы данных. При первом запуске информационной базы на новой версии платформы (а также при реструктуризации) во внутренние служебные таблицы и индексы СУБД или файловой базы вносятся изменения. Старая платформа не сможет корректно распознать обновленные служебные структуры и выдаст ошибку несовместимости формата.
2. Несовместимость файлов выгрузки. Файл выгрузки .dt, сформированный средствами новой платформы, не гарантирует обратной совместимости со старыми версиями технологической платформы. При попытке загрузить такой файл в базу под управлением старого релиза возникнет ошибка формата данных.
3. Формат служебных файлов кластера серверов. При смене веток платформы обновляются форматы конфигурационных файлов кластера серверов в каталоге srvinfo (настройки сеансов, фоновых заданий, списки баз). Возврат старой службы без восстановления резервной копии каталога кластера приводит к сбоям запуска сервера 1С.

Зависимость от используемых конфигураций

Перед переходом проанализируем режим совместимости конфигураций:

1. Если типовая конфигурация (например, БП 3.0 или ЗУП 3.0) была обновлена до релиза, требующего минимальный режим совместимости новой платформы, обратный откат платформы без восстановления старого релиза конфигурации станет невозможен.
2. Если в свойствах конфигурации режим совместимости установлен в значение Не использовать, конфигурация автоматически начинает задействовать новые платформенные механизмы, что повышает требования к тщательному предварительному тестированию.

Пошаговый план безопасного обновления платформы

Чтобы обновление прошло без рисков остановки бизнес-процессов, разберем по шагам правильный алгоритм действий:

1. Создание резервных копий. До установки новой платформы и до первого запуска базы в новом окружении обязательно создаем полную резервную копию средствами СУБД (бэкап базы данных) или делаем выгрузку в файл .dt на старой платформе.
2. Резервное копирование каталога кластера. Сохраняем копию каталога srvinfo кластера серверов 1С.
3. Установка новой платформы. Устанавливаем целевой релиз платформы на сервер и клиентские рабочие станции.
4. Обновление сопутствующих компонент. Если базы опубликованы на веб-сервере (IIS или Apache), обновляем модули расширения веб-сервера. Версия модуля веб-расширения должна строго соответствовать версии запущенной платформы. Также обновляем утилиты администрирования rac и консоль администрирования серверов.
5. Очистка кэша. При возникновении интерфейсных ошибок или некорректного отображения форм выполняем полную очистку локального кэша пользователей в каталогах %LocalAppData%\1C\1Cv8 и %AppData%\1C\1Cv8, а также серверного кэша.
6. Проверка внешних компонент и интеграций. Проверяем настройки безопасности и права запуска внешних компонент, так как в более новых версиях платформы действуют ужесточенные правила контроля безопасности.

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

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

1. Останавливаем службу кластера серверов 1С новой версии.
2. Восстанавливаем резервную копию базы данных, созданную средствами СУБД (или загружаем выгрузку .dt, сделанную на исходной платформе).
3. Восстанавливаем исходный каталог настроек кластера srvinfo (при необходимости).
4. Запускаем службу предыдущей версии платформы 1С.
5. Очищаем клиентский кэш на рабочих станциях перед повторным входом пользователей.