Обновление 1С 8.3 прошло неудачно: как вернуть конфигурацию к прошлому релизу

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

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

Перед откатом: что сломалось и на каком этапе обновления

Сначала поймите две вещи: в чём именно проблема и как далеко зашло обновление. От этого зависит, нужен ли откат вообще.

Обновление конфигурации в 1С 8.3 проходит в три этапа:

1. Загрузка новой версии в основную конфигурацию — файл .cfu или .cf применяется в Конфигураторе. Данные базы ещё не тронуты.
2. Обновление конфигурации базы данных — платформа меняет структуру таблиц (реструктуризация).
3. Обработчики обновления — при первом запуске в режиме 1С:Предприятие программа преобразует данные под новый релиз. В типовых конфигурациях часть обработчиков работает в фоне ещё часы и дни после запуска.

Чем дальше база ушла по этим этапам, тем сложнее вернуться.

🔍 Что проверить до решения об откате:

• 🧩 Внешние обработки и отчёты. После обновления часто ломаются именно они, а не сама типовая. Их обновляет разработчик или поставщик, откатывать базу ради них необязательно.
• 🧱 Расширения конфигурации . Расширение могло отключиться из-за несовместимости с новым релизом. Посмотрите список в Администрирование → Печатные формы, отчёты и обработки → Расширения.
• 🖥 Версия платформы. Новый релиз мог требовать платформу с номером не ниже указанного в описании обновления. Иногда достаточно поставить нужную платформу.
• ⏳ Отложенное обновление. Если программа пишет, что обновление данных ещё идёт, часть отчётов действительно будет неполной до его завершения. Статус видно в разделе Администрирование → Обслуживание, в группе результатов обновления программы.

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

Как вернуть прежнюю конфигурацию, пока база данных не обновлена

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

Порядок действий:

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

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

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

Восстановление базы из резервной копии

Главный способ отката после того, как обновление применено. Он возвращает базу в состояние на момент копии целиком: и конфигурацию, и данные.

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

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

Файл .dt — выгрузка информационной базы средствами платформы. Его создают через Администрирование → Выгрузить информационную базу в Конфигураторе.

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

Копия каталога файловой базы

Файловая база — это каталог с файлом 1Cv8.1CD. Если перед обновлением вы скопировали весь каталог, откат сводится к замене файлов:

1. Убедитесь, что в базе никто не работает .
2. Переименуйте текущий каталог базы, например в Buh_after_update.
3. Скопируйте на его место каталог из копии под прежним именем.
4. Запустите 1С и проверьте релиз.

Копировать каталог работающей базы нельзя: файл 1Cv8.1CD может оказаться несогласованным. Копию делают при закрытых сеансах.

Копия встроенным резервным копированием

В типовых конфигурациях на базе БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) для файловой базы есть встроенное копирование: Администрирование → Обслуживание → Резервное копирование и восстановление. Там же есть команда восстановления из ранее созданной копии. Копии в этом режиме — архивы каталога базы, по сути то же, что ручная копия каталога.

Перенос документов, введённых после обновления

Частая ситуация: обновили релиз в понедельник, проблему заметили в четверг. За три дня бухгалтер провёл сотню документов. После восстановления копии они исчезнут.

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

Выгрузка и загрузка XML

Для переноса объектов между базами с одинаковой структурой есть обработка «Выгрузка и загрузка данных XML» (файл ВыгрузкаЗагрузкаДанныхXML83.epf, распространяется на диске ИТС). Ею выгружают выбранные документы и справочники за период из обновлённой базы и загружают в восстановленную.

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

Конвертация данных 2.0 и 3.0

Если документов много, а структура релизов отличается, перенос делают через правила обмена.

Для КД 2.0 схема такая:

1. Обработкой MD83Exp.epf (входит в поставку КД 2.0) выгрузите структуру метаданных обеих баз: обновлённой и восстановленной.
2. В базе «Конвертация данных 2.0» загрузите обе структуры и создайте правила конвертации. Для большинства объектов КД сопоставит их автоматически, расхождения настраиваются вручную.
3. Сохраните правила в файл.
4. В обновлённой базе запустите обработку «Универсальный обмен данными в формате XML» (V8Exchan83.epf), укажите правила и выгрузите документы за нужный период.
5. Этой же обработкой загрузите файл в восстановленную базу.
6. Перепроведите загруженные документы.

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

Откат в клиент-серверном варианте

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

Порядок:

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

Примеры команд восстановления. Имена баз и пути подставьте свои.

-- MS SQL Server: восстановление копии поверх рабочей базы
RESTORE DATABASE [buh]
FROM DISK = N'D:\Backup\buh_before_update.bak'
WITH REPLACE, RECOVERY;

:: PostgreSQL: пересоздать базу и восстановить дамп формата custom
dropdb -U postgres buh
createdb -U postgres -T template0 buh
pg_restore -U postgres -d buh D:\Backup\buh_before_update.backup

Ещё несколько отличий клиент-серверного варианта:

• 🔐 Для восстановления копии СУБД нужен доступ администратора к серверу СУБД, у бухгалтера и даже у администратора 1С его может не быть.
• 🧹 После восстановления копии СУБД перезапуск службы агента сервера 1С обычно не нужен. Если пользователи видят ошибки кэша, его очищают с запуском клиента с ключом /ClearCache.
• 🖥 Версию платформы на сервере после отката менять не нужно: база прежнего релиза открывается и на более новой платформе.

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

Самый неприятный вариант. Чисто вернуть данные к прежнему релизу без копии нельзя: обработчики обновления уже переписали их под новую структуру.

Что можно сделать:

• 📦 Взять старую конфигурацию из шаблонов. Установленные релизы лежат в каталоге шаблонов, по умолчанию %APPDATA%\1C\1cv8\tmplts\1c\, в подпапке конфигурации и версии есть файл 1Cv8.cf.
• 🆕 Создать из шаблона новую чистую базу прежнего релиза и перенести в неё данные из обновлённой базы правилами КД, как описано выше. Это долго, но предсказуемо.
• 🧑‍💻 Обратиться к поставщику или разработчику. Часто быстрее исправить конкретную ошибку нового релиза расширением, чем откатывать всю базу.

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

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

Как подстраховаться перед следующим обновлением

Откат занимает минуты, если копия есть, и дни, если её нет. Поэтому подготовка важнее самого отката.

Несколько правил, которые экономят время при неудаче:

• 🧪 Обновляйте сначала тестовую копию. Разверните .dt в отдельную базу, обновите её и проверьте ключевые операции: проведение документов, печать, отчётность, обмены.
• 🏷 Подписывайте копии. Имя вроде buh_3.0.xxx_before_update.dt с номером релиза избавит от гадания, какая копия «та».
• 🗓 Не обновляйте в день сдачи отчётности или перед закрытием месяца. Оставьте себе запас времени на откат.
• 📌 Не перескакивайте через обязательные промежуточные релизы. Порядок перехода указан в описании обновления, нарушение порядка — частая причина ошибок обработчиков.
• 🔁 Для файловых баз включите встроенное резервное копирование по расписанию, если пользуетесь БСП-конфигурацией.

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