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