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

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

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

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

Почему откат возможен только через резервную копию

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

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

Подготовка: что сделать перед откатом

Прежде чем восстанавливать копию, зафиксируйте текущее состояние. Даже «сломанная» база может содержать данные, введённые пользователями после обновления: новые документы, платежи, заказы. При откате они будут потеряны, поэтому их нужно либо выгрузить (обработкой выгрузки-загрузки, через универсальный обмен XML), либо хотя бы зафиксировать списком для повторного ввода.

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

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

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

Как проверить, что копия подходит

Дата создания копии

Норма

Копия создана до запуска обновления

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

Копия сделана после обновления — в ней уже новый релиз

Версия конфигурации в копии

Норма

Совпадает с релизом, на который хотите откатиться

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

Копия ещё старше — потеряете данные за больший период

Целостность файла

Норма

dt загружается в тестовую базу без ошибок

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

Ошибки чтения при тестовой загрузке — копия повреждена

Способ 1: восстановление из dt-выгрузки через конфигуратор

Это универсальный способ, подходящий и для файловых, и для клиент-серверных баз, если копия снималась через «Администрирование → Выгрузить информационную базу» в конфигураторе.

Для файловой базы порядок такой: закройте все сеансы, откройте конфигуратор, выполните «Администрирование → Загрузить информационную базу» и укажите dt-файл. Платформа предупредит, что текущие данные будут замещены — подтвердите. После загрузки конфигуратор предложит перезапуститься для обновления конфигурации базы данных — соглашайтесь.

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

1. 1
   Завершите все сеансы пользователей и заблокируйте вход в базу
2. 2
   Сохраните отдельно данные, введённые после обновления (если они нужны)
3. 3
   Откройте конфигуратор с правами администратора
4. 4
   Выполните «Администрирование → Загрузить информационную базу» и выберите dt-файл
5. 5
   Подтвердите замещение данных и дождитесь окончания загрузки
6. 6
   Разрешите перезапуск конфигуратора и обновление конфигурации базы данных
7. 7
   Проверьте версию конфигурации и работоспособность базы, затем снимите блокировку

Способ 2: восстановление SQL-копии для клиент-серверной базы

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

Общий порядок: завершите сеансы 1С, отключите базу от пользователей (или переведите в single-user режим), восстановите бэкап средствами СУБД — в MS SQL это команда RESTORE DATABASE или мастер восстановления в Management Studio, в PostgreSQL — pg_restore или восстановление через psql. После восстановления проверьте, что кластер 1С видит базу и она открывается в конфигураторе.

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

Способ 3: откат только конфигурации через cf-файл (ограниченный сценарий)

Загрузка cf-файла предыдущего релиза («Конфигурация → Загрузить конфигурацию из файла») возвращает только метаданные и не трогает данные. Этот способ применим в строго ограниченной ситуации: обновление конфигурации базы данных было выполнено, но обработчики обновления не запускались или запуск первого сеанса ещё не состоялся, и данные не преобразовывались.

На практике это бывает, когда обновление установили в конфигураторе, но сразу обнаружили ошибку (например, конфликт с доработками) и базу в работу не запускали. В этом случае загрузите cf предыдущего релиза, обновите конфигурацию базы данных и проверьте целостность.

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

Сравнение способов отката

Восстановление из dt

Универсально для любой базы; полный откат данных и конфигурации. Минус — долго на больших базах, требует монопольного доступа.

Восстановление SQL-бэкапа

Быстро для больших клиент-серверных баз; точное состояние на момент копии. Минус — нужен доступ к СУБД и навыки администрирования.

Загрузка cf предыдущего релиза

Быстро, но возвращает только конфигурацию. Подходит, только если обработчики обновления не выполнялись; иначе приведёт к рассогласованию данных.

Что делать, если резервной копии нет

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

Второй вариант — точечно исправить последствия: если проблема в конкретном обработчике обновления или доработке, опытный разработчик может скорректировать код и повторно выполнить проблемный обработчик. Это работает, когда сам релиз корректен, а сломалась прикладная логика.

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

Проверка базы после отката

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

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

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

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

Можно ли откатить обновление 1С без резервной копии?

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

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

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

Работает ли откат через загрузку cf-файла старого релиза?

Только если обработчики обновления ещё не выполнялись и данные не преобразовывались — например, обновление установили в конфигураторе, но базу в работу не запускали. Если пользователи уже работали в новом релизе, загрузка старого cf вызовет рассогласование структуры данных и ошибки.

Нужно ли откатывать платформу вместе с конфигурацией?

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

Как откатить обновление в файловой базе, если копия — это просто копия каталога?

Если перед обновлением копировали каталог базы целиком, достаточно завершить все сеансы и заменить текущий каталог базы сохранённым. Убедитесь, что в момент замены никто не работает с файлом 1Cv8.1CD, иначе файл может быть повреждён. После замены откройте базу и проверьте версию конфигурации.

Откатятся ли настройки и дополнительные отчёты при восстановлении копии?

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