Что делать, если обновление 1С прошло неудачно

Откатить релиз конфигурации 1С можно несколькими способами, и выбор зависит от одного факта: успели ли вы обновить конфигурацию базы данных (клавиша F7). Если ещё не успели — хватит одной команды «Вернуться к конфигурации БД», и база останется нетронутой. Если изменения уже применены — понадобится резервная копия либо загрузка предыдущего .cf.

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

С чего начать: оцениваем ситуацию перед откатом

Сначала определите, на каком этапе остановилось обновление. От этого зависит, какой способ сработает и потеряете ли вы данные.

• 🔹 Загрузили новую конфигурацию, но F7 ещё не нажимали. Самый лёгкий случай: откат мгновенный и без потерь.
• 🔹 Обновление конфигурации базы данных уже прошло. Структура базы изменилась — простым возвратом не обойтись, нужна копия или старый .cf.
• 🔹 После обновления пользователи успели поработать. Восстановление из копии вернёт и структуру, и данные на момент копии — всё, что внесли позже, придётся заносить заново.

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

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

Чтобы было проще сопоставить способы между собой, вот их короткая сводка — когда применять и чем рискуете:

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

Возврат к конфигурации базы данных — когда F7 ещё не нажата

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

Порядок действий в Конфигураторе:

1. Откройте базу в режиме Конфигуратор.
2. Меню Конфигурация → Конфигурация базы данных → Вернуться к конфигурации БД.
3. Подтвердите откат. Основная конфигурация снова совпадёт с той, что работает в базе.

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

Восстановление из резервной копии — самый надёжный путь

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

Файловая база (.dt). Выгрузку делают и загружают через Конфигуратор:

1. Меню Администрирование → Загрузить информационную базу.
2. Укажите файл .dt, снятый перед обновлением.
3. Подтвердите — платформа полностью перезапишет текущую базу содержимым копии.

Клиент-серверная база (SQL Server или PostgreSQL). Здесь копию восстанавливают средствами СУБД — через SSMS для MS SQL или pg_restore для PostgreSQL. После восстановления в самой 1С делать ничего не нужно: вернётся и конфигурация, и данные.

Загрузка .dt и восстановление средствами СУБД требуют монопольного доступа. В клиент-серверном варианте завершите сеансы через консоль кластера или установите блокировку начала сеансов, иначе платформа не даст перезаписать базу.

Загрузка предыдущего релиза из файла конфигурации

Когда резервной копии нет, но сохранён файл прежней конфигурации (.cf) или остался дистрибутив старого релиза, откат делают загрузкой этой конфигурации поверх текущей.

1. В Конфигураторе: Конфигурация → Загрузить конфигурацию из файла.
2. Выберите .cf предыдущего релиза. Если заранее не сохраняли свой файл, возьмите поставочный .cf старой версии из каталога шаблонов (tmplts) или скачайте дистрибутив релиза повторно.
3. После загрузки выполните Конфигурация → Конфигурация базы данных → Обновить конфигурацию базы данных (F7).

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

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

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

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

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

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

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

Частичный откат: исключение объектов и разбор конфликтов

Иногда нужно вернуть не весь релиз, а только часть изменений — например, отменить правку одной подсистемы, оставив остальное. Для этого вместо полной загрузки используют сравнение с объединением.

1. Меню Конфигурация → Сравнить, объединить с конфигурацией из файла.
2. Укажите .cf предыдущего релиза. Откроется окно сравнения-объединения со списком различий.
3. Снимите флажки с объектов, которые откатывать не нужно, — они останутся в текущем виде.
4. Для объектов с конфликтами задайте, какую версию взять: из файла (откат) или оставить текущую.
5. Нажмите «Выполнить», затем обновите конфигурацию базы данных.

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

Частичное объединение — инструмент для аккуратной правки, а не для срочного восстановления. Когда база «легла» целиком, быстрее и безопаснее восстановить её из копии, чем вручную разбирать десятки конфликтов.

Тестирование и ввод базы в работу после отката

Откат меняет структуру базы, поэтому перед тем как пускать пользователей, базу нужно проверить.

1. Запустите Администрирование → Тестирование и исправление. Включите проверку логической и ссылочной целостности и реиндексацию таблиц. Для файловой базы дополнительно помогает утилита chdbfl.exe.
2. Зайдите в базу в режиме 1С:Предприятие и проверьте ключевые участки: откройте несколько документов, перепроведите один-два свежих, сформируйте привычный отчёт. Если всё открывается и считается — структура цела.
3. Убедитесь, что номер релиза в разделе «О программе» соответствует тому, к которому откатывались.
4. Снимите блокировку начала сеансов и верните пользователям доступ.

Отдельно предупредите пользователей, какие данные пропали, если откат делался восстановлением из копии. Лучше заранее собрать список введённых после копии документов, чтобы потом занести их повторно без потерь.

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

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