Администрирование · 12 мин
Как сделать даунгрейд конфигурации 1С
Как откатить конфигурацию 1С на более раннюю версию: подготовка, способы даунгрейда, проверка результата, типичные ошибки и ответы на частые вопросы.
Даунгрейд конфигурации 1С — это возврат информационной базы на более раннюю версию прикладного решения после обновления. Такая необходимость возникает, когда новое обновление содержит ошибки, ломает доработки, меняет привычные алгоритмы учёта или оказывается несовместимым с другими системами. В отличие от обычного обновления, откат — операция нештатная: платформа 1С не предоставляет кнопки «вернуться назад», поэтому действовать нужно осознанно и с подготовкой.
Главная сложность даунгрейда в том, что при обновлении часто выполняются процедуры преобразования данных: переносятся значения в новые реквизиты, пересчитываются итоги, изменяется структура регистров. Эти изменения необратимы «сами по себе», и простая загрузка старой конфигурации поверх базы с уже преобразованными данными может привести к потере информации. Поэтому безопасный откат почти всегда строится вокруг резервной копии, сделанной до обновления.
Ниже разобраны рабочие сценарии: от простого восстановления из копии до ручного отката через конфигуратор, а также проверка результата и типичные ошибки, из-за которых база приходит в нерабочее состояние.
Когда даунгрейд оправдан, а когда лучше исправить проблему иначе
Прежде чем откатывать конфигурацию, важно убедиться, что проблема действительно требует возврата версии. Многие сбои после обновления решаются проще: очисткой кэша, повторным запуском обработчиков обновления, установкой исправительного патча от вендора. Полный даунгрейд — крайняя мера, потому что он затрагивает данные и требует остановки работы пользователей.
Откат оправдан, если обновление критично нарушило учёт (неверно считаются налоги, не проводятся документы, сломана интеграция), а исправления от поставщика ждать нельзя. Также даунгрейд применяют, когда обновление случайно установили на рабочую базу вместо тестовой или обновили конфигурацию, которую планировали снять с поддержки и дорабатывать самостоятельно.
Как выбрать действие
Подготовка: что сделать до отката
Первый и обязательный шаг — зафиксировать текущее состояние. Даже если база работает с ошибками, сделайте полную резервную копию: для файловой базы — выгрузку в dt через конфигуратор, для клиент-серверной — штатный бэкап средствами СУБД (MS SQL, PostgreSQL) плюс выгрузку dt. Это страховка на случай, если откат пройдёт неудачно и потребуется вернуться хотя бы к текущему состоянию.
Далее найдите источник прежней версии. Вариантов несколько: резервная копия базы до обновления, файл конфигурации .cf нужной версии (можно получить из дистрибутива обновления или выгрузить из копии базы), либо полный дистрибутив прежнего релиза с портала поставщика. Убедитесь, что версия конфигурации в источнике действительно та, на которую вы откатываетесь, — номер версии виден в конфигураторе в свойствах конфигурации.
Определите, какие данные введены в базу после обновления: документы, справочники, настройки. Эти данные при откате из копии будут потеряны, и их нужно будет либо внести повторно вручную, либо перенести обработкой. Составьте список таких объектов заранее — это сэкономит часы на этапе восстановления.
Способ 1: восстановление из резервной копии до обновления
Это основной и рекомендуемый способ даунгрейда. Для файловой базы откройте конфигуратор, загрузите выгрузку dt, сделанную до обновления (меню «Администрирование» — «Загрузить информационную базу»). Для клиент-серверной базы восстановите бэкап средствами СУБД в ту же или новую базу и при необходимости обновите регистрацию в кластере.
После восстановления база вернётся к состоянию на момент копии: прежняя версия конфигурации, прежние данные. Все изменения, сделанные после создания копии, отсутствуют — их нужно донести. Небольшой объём документов проще ввести вручную по распечаткам или журналам. При большом объёме используют типовую обработку «Выгрузка и загрузка данных XML» или универсальный обмен: из актуальной (сломанной) копии базы выгружают документы за период и загружают в восстановленную.
Важный нюанс: переносить данные нужно между базами с одинаковой версией конфигурации. Если вы выгружаете из обновлённой базы, а загружаете в старую версию, структуры объектов могут не совпасть — новые реквизиты просто не перенесутся. Проверяйте критичные поля (суммы, ставки НДС, договоры) после загрузки выборочно.
- 1Сделайте резервную копию текущего (проблемного) состояния базы
- 2Найдите копию или dt-выгрузку, созданную до обновления, и проверьте версию конфигурации в ней
- 3Завершите работу пользователей и установите блокировку сеансов
- 4Восстановите базу из копии: загрузка dt для файловой, restore для клиент-серверной
- 5Перенесите документы и справочники, введённые после обновления
- 6Проведите восстановленные документы и сверьте ключевые отчёты
- 7Снимите блокировку и сообщите пользователям о возврате к работе
Способ 2: откат через конфигуратор без копии
Если резервной копии до обновления нет, остаётся вариант загрузить в базу конфигурацию прежней версии из файла .cf. В конфигураторе откройте «Конфигурация» — «Загрузить конфигурацию из файла» и укажите cf нужного релиза. Платформа предупредит, что загружаемая версия старше текущей, — подтвердите операцию, затем выполните обновление конфигурации базы данных (F7).
При этом способе платформа попытается привести структуру базы к старой конфигурации: реквизиты и объекты, добавленные в новой версии, будут удалены вместе с данными. Именно здесь кроется главный риск: если при прошлом обновлении обработчики перенесли данные из старых полей в новые, после отката новые поля исчезнут, а старые окажутся пустыми — информация будет потеряна безвозвратно.
Также конфигурация может быть на поддержке с запретом изменений — тогда сначала потребуется включить возможность изменения («Поддержка» — «Настройка поддержки»). Учтите, что после такого отката конфигурация окажется в состоянии, не предусмотренном поставщиком, и последующие штатные обновления могут потребовать ручной корректировки.
Особенности для клиент-серверных баз и подписанных расширений
В клиент-серверном варианте откат выполняется на уровне СУБД: восстановление базы из бэкапа SQL-сервера автоматически возвращает и конфигурацию, хранящуюся внутри базы. Отдельно загружать cf не требуется. После восстановления проверьте, что в консоли кластера база доступна, а блокировки регламентных заданий и сеансов настроены корректно — часто после восстановления копии забывают отключить регламентные задания, и они начинают выполняться параллельно с рабочей базой.
Отдельного внимания заслуживают расширения конфигурации и внешние компоненты. Расширение, разработанное под новую версию, после отката может оказаться несовместимым со старой и отключиться с ошибкой. Перед откатом зафиксируйте список установленных расширений и их версии, после отката — проверьте каждое и при необходимости установите прежнюю версию расширения.
Если используются внешние печатные формы, обработки и интеграционные сервисы, привязанные к объектам новой версии, их тоже нужно проверить: обращение к удалённому реквизиту вызовет ошибку при выполнении.
Проверка результата после отката
После завершения даунгрейда нельзя сразу открывать доступ пользователям. Сначала запустите базу в режиме предприятия под полными правами и убедитесь, что не запускаются обработчики обновления — их отсутствие означает, что версия конфигурации консистентна данным. Затем выполните тестирование и исправление в конфигураторе (минимум — проверку логической целостности и ссылочной целостности).
Далее сверьте ключевые показатели: оборотно-сальдовую ведомость, остатки по складу, взаиморасчёты по основным контрагентам. Значения должны совпадать с данными на момент создания копии плюс восстановленные документы. Проверьте открытие основных журналов документов, проведение типового документа, формирование регламентированных отчётов.
Как проверить результат
Соответствует целевой (старой) версии
Осталась новая версия или база требует обновления
База открывается без обработчиков обновления и ошибок
Появляется окно обновления версии или ошибки метаданных
Совпадают с данными на дату копии с учётом восстановленных документов
Расхождения сумм, пустые регистры
Документ проводится, движения формируются
Ошибки обращения к реквизитам или модулям
Все подключены и работают
Расширение отключено из-за несовместимости
Типичные ошибки и как их избежать
Самая распространённая ошибка — откат без резервной копии текущего состояния. Даже «сломанная» база содержит данные, введённые после обновления, и без копии они будут потеряны навсегда. Вторая частая ошибка — восстановление копии «поверх» рабочей базы без блокировки сеансов: пользователи продолжают вводить документы, которые затем исчезают.
Также часто забывают про отложенные обработчики обновления: если прошлое обновление завершилось не полностью, откат из копии может привести к конфликту версий. Перед восстановлением проверьте в копии, что обновление на тот момент было завершено полностью. Наконец, после отката нередко пропускают сверку отчётов — и расхождения обнаруживаются только при закрытии периода, когда исправлять сложнее.
Полезная привычка: перед любым обновлением конфигурации сохраняйте не только dt-выгрузку, но и cf-файл текущей версии и список установленных расширений. Тогда откат займёт меньше часа, а не целый рабочий день с поиском нужного дистрибутива.
Частые вопросы о даунгрейде конфигурации 1С
Можно ли откатить конфигурацию штатными средствами без резервной копии?
Частично — через загрузку cf-файла прежней версии в конфигураторе. Но это не отменяет преобразования данных, выполненные обработчиками обновления. Способ подходит только если данные после обновления почти не менялись, и всегда требует предварительной копии текущего состояния.
Что будет с документами, введёнными после обновления, при восстановлении копии?
Они исчезнут вместе с состоянием базы. Их нужно перенести обработкой обмена (например, «Выгрузка и загрузка данных XML») или ввести повторно вручную. Перед откатом зафиксируйте список таких документов по журналам.
Нужно ли откатывать платформу 1С вместе с конфигурацией?
Обычно нет: старые версии конфигураций, как правило, работают на более новых релизах платформы. Откат платуры требуется редко — только если ошибка вызвана именно обновлением платформы, а не прикладного решения.
Как откатить базу, если она находится на поддержке без возможности изменения?
Восстановление из копии не требует снятия с поддержки. Для загрузки cf-файла сначала включите возможность изменения в настройках поддержки, но учтите, что это усложнит дальнейшие штатные обновления.
Сколько времени занимает даунгрейд?
При наличии свежей копии и небольшого объёма данных для переноса — от одного до нескольких часов, включая проверку. Без копии и с необходимостью ручного восстановления данных сроки непредсказуемы и могут занять несколько дней.
Можно ли откатить только часть изменений, например один модуль?
Да, если проблема локализована: можно сравнить конфигурацию со старой версией и вручную перенести нужные процедуры или формы. Это требует навыков разработки, но позволяет избежать полного отката и потери данных.
Что важно запомнить
Безопасный даунгрейд строится на резервной копии до обновления: восстановили базу, перенесли новые документы, проверили отчёты и расширения. Откат через загрузку старого cf — запасной вариант с риском потери преобразованных данных. Перед любым сценарием зафиксируйте текущее состояние базы.