Как откатить 1С на предыдущий релиз

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

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

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

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

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

Даже если у вас сохранился CF-файл старого релиза, загрузить его поверх обновлённой базы нельзя: конфигуратор либо откажется выполнять загрузку из-за несоответствия версий, либо при принудительной загрузке вы получите неконсистентную базу, в которой структура данных не соответствует метаданным. Такая база будет падать с ошибками при обращении к изменённым объектам.

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

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

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

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

1. 1
   Сделайте DT-выгрузку текущей проблемной базы как страховку
2. 2
   Составьте список данных, введённых после обновления
3. 3
   Найдите резервную копию, сделанную до обновления, и проверьте её целостность
4. 4
   Предупредите пользователей о времени простоя и завершите их сеансы
5. 5
   Зафиксируйте номер релиза, на который откатываетесь, и версию платформы

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

Откат файловой базы из DT-выгрузки

Самый распространённый сценарий для небольших баз. Если перед обновлением была сделана выгрузка в DT, восстановление занимает несколько минут.

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

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

Откат клиент-серверной базы через СУБД

В клиент-серверном варианте (MS SQL, PostgreSQL) корректный способ отката — восстановление резервной копии средствами СУБД, сделанной до обновления. DT-выгрузка для больших баз часто неприменима из-за длительности и ограничений на размер.

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

RESTORE DATABASE [TradeBackup] FROM DISK = N'D:\Backups\trade_before_update.bak' WITH REPLACE, RECOVERY;

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

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

Ситуация неприятная, но не всегда безнадёжная. Варианты зависят от того, на каком этапе обнаружена проблема.

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

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

Перенос данных, введённых после обновления

Главная цена отката — потеря работы пользователей за период между обновлением и восстановлением. Минимизировать её можно несколькими способами.

Небольшой объём документов проще ввести вручную по распечаткам или списку из журнала. Для массового переноса используйте обработку «Выгрузка и загрузка данных XML» из состава БСП — но она требует идентичности конфигураций источника и приёмника, поэтому между разными релизами напрямую не сработает. В этом случае данные выгружают через промежуточную базу того же нового релиза, а затем конвертируют, либо пишут перенос через «Конвертацию данных».

Практичный компромисс: переносить только критичные данные (проведённые документы за период, новые договоры и контрагенты), а настройки и второстепенные справочники восстановить вручную. Попытка перенести «всё» часто занимает больше времени, чем сам откат.

Проверка результата после отката

После восстановления не спешите запускать пользователей. Сначала проверьте базу самостоятельно: откройте режим предприятия, убедитесь, что номер релиза в «О программе» соответствует ожидаемому, запустите типовые отчёты за последние периоды и сверьте ключевые итоги (обороты, остатки) с данными до обновления.

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

Типичные ошибки при откате

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

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