Как безопасно откатить изменения конфигурации в 1С 8.3

Откатить конфигурацию 1С к предыдущей версии можно пятью путями: загрузить сохранённый файл .cf, вернуть объекты поставщика через механизм поддержки, загрузить полную выгрузку .dt, получить раннюю версию из хранилища конфигурации или восстановить базу на уровне СУБД. Все операции делаются в Конфигураторе или средствами сервера баз данных — быстрее всего через загрузку .cf, если менялась только конфигурация, а данные трогать не нужно.

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

Когда нужен откат и что именно откатывают

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

Типичные поводы для отката:

• 🔧 неудачное обновление: после установки нового релиза перестали открываться формы или проводиться документы;
• 🧩 ошибка в доработке: программист внёс изменение в модуль, и в рабочей базе появились ошибки;
• 🗑️ случайно удалён или испорчен объект метаданных;
• 📉 после обновления изменилась структура, и нужно вернуться к стабильной версии, пока ищут причину.

Выбор способа зависит от того, нужно ли сохранить данные:

Подготовка: резервная копия и монопольный режим

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

Операции, которые меняют структуру конфигурации базы данных или загружают базу целиком, требуют монопольного доступа — пока они идут, другие пользователи работать не смогут. К таким относятся загрузка .dt, загрузка .cf с последующим обновлением структуры и тестирование базы .

Резервную копию .dt делают через меню Администрирование → Выгрузить информационную базу…. Отдельно конфигурацию сохраняют через Конфигурация → Сохранить конфигурацию в файл… — получится файл .cf, который и есть «слепок» структуры без данных.

Загрузка файла конфигурации .cf и возврат к поставщику

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

Если у вас сохранён .cf стабильной версии:

1. Откройте базу в режиме Конфигуратор.
2. Выберите Конфигурация → Загрузить конфигурацию из файла… и укажите сохранённый .cf.
3. На вопрос об обновлении согласитесь — платформа заменит основную конфигурацию.
4. Выполните Обновление конфигурации базы данных (клавиша F7). На этом шаге нужен монопольный доступ.

Загрузка конфигурации из файла полностью заменяет основную конфигурацию — все несохранённые доработки будут потеряны. Поэтому и делают резервную копию .cf заранее.

Если отдельного файла нет, но нужно вернуть типовые объекты к состоянию поставщика, используйте механизм поддержки. Понадобится дистрибутивный .cf нужного релиза (он лежит в каталоге шаблонов обновлений). Откройте Конфигурация → Сравнить, объединить с конфигурацией из файла…, укажите этот .cf и в окне сравнения отметьте объекты, которые нужно привести к версии поставщика. Так можно откатить только испорченную часть, не трогая остальное.

Настройки поддержки смотрят в Конфигурация → Поддержка → Настройка поддержки…. Если конфигурация снята с поддержки, часть автоматических сравнений будет недоступна — тогда проще загрузить .cf целиком.

Есть и более аккуратный вариант, если неудачное изменение пришло через расширение конфигурации . Расширения (файлы .cfe) подключаются поверх основной конфигурации и не меняют её дерево. Если ошибку внесло именно расширение, откатывать основную конфигурацию не нужно — достаточно отключить или удалить расширение . В режиме предприятия это делается в разделе с настройками администрирования, пункт Печатные формы, отчёты и обработки → Расширения; снимите флажок Используется у проблемного расширения или удалите его. Это обратимо и не затрагивает ни данные, ни типовую конфигурацию , поэтому с расширений стоит начинать, если доработки оформлены именно так.

Полное восстановление из выгрузки .dt

Выгрузка .dt — это дамп всей информационной базы: и конфигурация, и данные в одном файле. Загрузка .dt возвращает базу ровно к тому состоянию, в котором её выгрузили.

Порядок:

1. Все пользователи выходят из базы (для файловой — закрывают, для серверной — блокируем сеансы).
2. В Конфигураторе выбираем Администрирование → Загрузить информационную базу….
3. Указываем нужный .dt и подтверждаем.
4. После загрузки платформа перезапустится.

Поэтому .dt подходит, когда нужно именно «вернуть всё как было» на конкретную дату — например, после фатального сбоя обновления. Если же данные менять нельзя, а испорчена только конфигурация, .dt — неподходящий инструмент, лучше загрузить .cf.

Частая проблема: загрузка .dt падает с ошибкой на больших базах. Выгрузка/загрузка .dt рассчитана на относительно небольшие базы; для крупных рабочих баз надёжнее восстановление средствами СУБД (см. ниже).

Практический совет по хранению копий: держите несколько .dt за разные даты, а не одну «последнюю». Если сбой заметили не сразу, единственная свежая копия может уже содержать ту же ошибку, и откатываться будет не на что. Нумеруйте файлы по дате — например, base_2026-10-01.dt — и складывайте не на тот же диск, где лежит рабочая база.

Откат версии через хранилище конфигурации

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

1. Подключитесь к хранилищу: Конфигурация → Хранилище конфигурации → Открыть хранилище конфигурации….
2. Откройте историю хранилища и найдите нужную версию по номеру и комментарию.
3. Выполните получение этой версии в основную конфигурацию.
4. Обновите конфигурацию базы данных (F7).

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

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

Как определить момент отката: журнал регистрации и история

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

Журнал регистрации не хранит саму конфигурацию и не умеет её откатывать. Но по нему видно, в какой день база ещё работала нормально, а когда появились ошибки. По этой дате вы выбираете подходящую резервную копию .dt или .cf.

Открыть журнал можно в режиме предприятия через раздел с настройками администрирования (пункт Журнал регистрации) или из Конфигуратора — Администрирование → Журнал регистрации. Отфильтруйте события по дате и важности, чтобы отсечь штатную работу и увидеть сбои и ошибки.

Отдельно полезно сверить основную конфигурацию и конфигурацию базы данных: Конфигурация → Сравнить конфигурации…. Если они различаются, значит, изменения уже есть в дереве, но ещё не применены к базе — такой «неприменённый» откат можно отменить простой загрузкой прежнего .cf без потери данных.

Восстановление базы на уровне СУБД

Для клиент-серверных баз (MS SQL Server, PostgreSQL) надёжнее всего откатывать не средствами 1С, а восстановлением резервной копии самой СУБД. Это быстрее, чем .dt, и штатно работает даже на больших базах.

Общая логика:

• регулярный бэкап базы настраивается на стороне СУБД (план обслуживания в SQL Server, pg_dump/pg_basebackup в PostgreSQL);
• для отката администратор восстанавливает базу из нужного бэкапа средствами сервера;
• в 1С при этом ничего загружать не нужно — после восстановления база откроется в том состоянии, что была на момент копии.

Для файловой базы (.1CD) аналог — просто замена файла базы из копии каталога. База должна быть закрыта у всех, иначе файл будет занят. Копировать «живой» .1CD работающей базы нельзя — копия получится повреждённой.

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

Частые ошибки при откате

Эти ошибки чаще всего превращают простой откат в потерю данных:

• 📁 Откатили .dt в рабочей базе без предупреждения пользователей. Введённые после выгрузки документы исчезли. Прежде чем загружать .dt или восстанавливать СУБД, всегда проверяйте дату копии и предупреждайте коллег.
• 🔁 Перепутали «конфигурацию» и «базу целиком». Чтобы вернуть только сломанную структуру, нужен .cf, а не .dt. Загрузка .dt ради отката одной формы уничтожит свежие данные.
• 🧊 Забыли обновить конфигурацию базы данных. После загрузки .cf изменения живут только в основной конфигурации, пока не нажали F7. Пользователи продолжат работать на старой структуре, и будет непонятно, «почему откат не сработал».
• 💾 Не сделали копию перед откатом. Если прежняя версия оказалась тоже с проблемой, вернуться уже некуда.
• 🧱 Пытались загрузить .dt на большой серверной базе и получили ошибку. Для таких баз используйте восстановление средствами СУБД, а не выгрузку платформы.

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