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