Как сделать даунгрейд 1С: пошаговая инструкция по откату версии

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

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

Ниже разобраны оба сценария с конкретными шагами, условиями, при которых откат возможен, и способами проверки результата.

Когда даунгрейд оправдан, а когда лучше исправить проблему

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

Даунгрейд оправдан, если новая версия содержит подтверждённую ошибку, исправление которой выйдет не скоро, а работа организации парализована. Также откат уместен, когда критичная внешняя система (оборудование, обмен с контрагентом, банк-клиент) несовместима с новым релизом и обновить её нельзя.

Маршрут решения

Как выбрать действие

Ошибка появилась сразу после обновления платформы и исчезает после очистки кэшаОткат не нужен — проблема в кэше, очистите его и проверьте работу

Конфигурация обновилась с ошибками, но копия базы до обновления естьВосстановите базу из копии и отложите обновление до выхода исправления

Резервной копии нет, а база уже конвертирована новой платформойНе откатывайте — ищите исправление ошибки в текущей версии или обращайтесь к специалисту

Критичная внешняя компонента несовместима с новым релизом платформыУстановите предыдущий релиз платформы параллельно и проверьте совместимость

Подготовка: резервная копия и оценка рисков

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

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

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

Откат платформы 1С на предыдущий релиз

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

Порядок действий для файловой базы:

1. 1
   Скачайте дистрибутив прежнего релиза платформы с портала portal.1c.ru и установите его — версии встанут параллельно
2. 2
   Откройте список информационных баз, выделите нужную базу и нажмите «Изменить»
3. 3
   На втором шаге укажите версию платформы вручную, выбрав прежний релиз из списка установленных
4. 4
   Попробуйте открыть базу: если платформа не выполняла конвертацию формата, база откроется сразу
5. 5
   Если появляется сообщение о несовместимости версии формата — восстановите базу из копии, сделанной до обновления
6. 6
   Проверьте работу ключевых операций: проведение документов, отчёты, обмены, печать

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

Ограничение конвертации формата базы

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

Откат конфигурации на предыдущую версию

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

Корректный способ отката конфигурации — восстановление базы целиком из копии, сделанной до обновления. Для файловой базы замените файл 1Cv8.1CD на архивный или загрузите выгрузку .dt через конфигуратор («Администрирование» → «Загрузить информационную базу»). Для клиент-серверной базы восстановите бэкап средствами СУБД или загрузите .dt.

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

Если копии нет, а откат нужен

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

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

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

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

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

Версия платформы и конфигурации в окне «О программе»

Норма

Отображаются прежние релизы, на которые выполнялся откат

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

Версия осталась новой — откат не выполнен или восстановлена не та копия

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

Норма

Документ проводится без ошибок, движения формируются

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

Ошибки проведения, ругань на отсутствующие объекты метаданных

Журнал регистрации после входа

Норма

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

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

Повторяющиеся ошибки обработчиков обновления — база в несогласованном состоянии

Работа расширений и внешних обработок

Норма

Расширения подключаются, обработки открываются

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

Расширения отключены из-за несовместимости — требуется их перепроверка

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

Типичные ошибки при даунгрейде

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

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

Как не допустить повторения ситуации

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

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

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

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

Можно ли откатить конфигурацию, если резервной копии нет?

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

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

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

Нужно ли удалять новую версию платформы после отката?

Нет, и делать это сразу не стоит. Версии платформы устанавливаются параллельно и не мешают друг другу. Оставьте новый релиз на случай повторного обновления после выхода исправления. Удалять его разумно только при дефиците места на диске или по требованиям регламента ИБ.

Что делать с данными, введёнными после неудачного обновления?

Перед восстановлением базы из копии выгрузите эти данные: документы и справочники можно перенести обработкой «Выгрузка и загрузка данных XML» между одинаковыми по структуре объектами или универсальным обменом. После отката загрузите их в восстановленную базу и сверьте итоги по ключевым регистрам.

Почему после отката перестали работать расширения?

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

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

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