Неудачное обновление или сбой: возвращаем рабочую конфигурацию 1С

Вернуть конфигурацию 1С можно четырьмя способами, от мягкого к жёсткому. Если изменения ещё не применены к базе — Конфигурация → Конфигурация базы данных → Вернуть к конфигурации БД. Если применены — загрузить сохранённый до обновления файл .cf. Если пострадали и данные — восстановить базу целиком из выгрузки .dt, копии файла 1Cv8.1CD или бэкапа SQL.

Выбор зависит от двух вопросов: что именно сломано (код конфигурации или сами данные) и успели ли пользователи поработать после сбоя. Всё описанное относится к платформе 8.3 и подходит для любой типовой конфигурации: Бухгалтерии, ЗУП, УТ, КА.

С чего начать: оценка ущерба до любого отката

Не откатывайте ничего, пока не поняли, что случилось. Поспешный откат часто стоит дороже самого сбоя: можно потерять документы, введённые после обновления.

Ответьте себе на пять вопросов:

• 🔍 Что видит пользователь? Ошибка при запуске, ошибка в одном документе, «битые» данные, база вообще не открывается.
• 🕒 Когда это началось? Сразу после обновления, после доработки программиста, после аварийного отключения питания.
• 🧩 Применено ли изменение к базе? Если Конфигуратор при запуске пишет, что конфигурация базы данных не соответствует сохранённой, — обновление загружено, но не применено.
• 👥 Работали ли люди после сбоя? Каждый час работы — это документы, которые пропадут при восстановлении старой копии.
• 💾 Какие копии есть? Файл .cf прошлого релиза, выгрузка .dt, копия каталога файловой базы, бэкап SQL. Проверьте дату каждой копии.

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

Мягкий откат: вернуть основную конфигурацию к конфигурации БД

В Конфигураторе у каждой базы две конфигурации. Основная — та, которую вы редактируете и в которую загружается обновление. Конфигурация базы данных — та, с которой реально работают пользователи. Пока вы не нажали «Обновить конфигурацию базы данных» (F7), изменения живут только в основной.

Это значит, что неудачное обновление, которое прервалось или выдало ошибку на этапе загрузки, можно отменить без потерь:

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

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

Откат обновления конфигурации из файла .cf

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

Где взять файл прошлой версии

• 📁 Ваша копия. Перед обновлением сохраните её: Конфигурация → Сохранить конфигурацию в файл.
• 📦 Каталог шаблонов. Установленные релизы типовых конфигураций лежат в каталоге шаблонов, по умолчанию %APPDATA%\1C\1cv8\tmplts\1c\. Внутри — папка конфигурации и подпапки по номерам версий, в каждой есть файл 1Cv8.cf. Это чистая поставка поставщика, без ваших доработок.
• 🗄️ Выгрузка .dt. Из неё можно поднять временную базу и уже оттуда сохранить .cf.

Порядок загрузки

1. Выгоните пользователей и сделайте свежую выгрузку .dt: Администрирование → Выгрузить информационную базу.
2. Конфигурация → Загрузить конфигурацию из файла, выберите .cf прежнего релиза.
3. Нажмите F7 или Конфигурация → Обновить конфигурацию базы данных.
4. Внимательно прочитайте окно «Реорганизация информации»: в нём перечислены изменения структуры данных.
5. Примите изменения и запустите 1С:Предприятие для проверки.

Почему откат «только кода» бывает опасен

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

Если вернуть старый .cf поверх уже обновлённых данных, произойдёт три вещи:

• ❌ новые реквизиты и регистры будут удалены вместе с данными в них;
• ❌ данные, преобразованные обработчиками, останутся в новом виде, а старый код ждёт старый;
• ❌ ошибки вылезут не сразу, а через неделю — в отчётах и закрытии месяца.

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

Как ведёт себя поддержка конфигурации при откате

Механизм поддержки отвечает за связь вашей конфигурации с поставщиком. Он хранит конфигурацию поставщика и правила для каждого объекта: изменять можно или нельзя.

Через поддержку нельзя «обновиться назад». Команда Конфигурация → Поддержка → Обновить конфигурацию принимает только файлы обновления на более высокую версию. Файл прошлого релиза она не примет.

Что делать вместо этого:

1. Откатитесь загрузкой сохранённого .cf, как описано выше. Файл .cf несёт с собой настройки поддержки, поэтому после загрузки вернётся и прежняя конфигурация поставщика, и прежние правила изменения объектов.
2. Проверьте результат: Конфигурация → Поддержка → Настройка поддержки. В окне видна версия поставщика — она должна совпадать с той, к которой вы откатывались.
3. Если загрузили «чистый» 1Cv8.cf из шаблонов, конфигурация снова встанет на полную поддержку без возможности изменения. Доработки нужно будет переносить заново.

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

Сравнение и объединение: вернуть только испорченные объекты

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

Точечный возврат делают через сравнение с сохранённым файлом:

1. Конфигурация → Сравнить, объединить с конфигурацией из файла, выберите .cf с рабочим состоянием.
2. Конфигуратор покажет дерево объектов с отличиями. Включите отбор «Показывать только отличия», чтобы список стал обозримым.
3. Снимите все флажки в корне дерева, затем отметьте только объекты, которые нужно вернуть.
4. Для модулей можно открыть сравнение по процедурам и взять из файла лишь нужные функции.
5. Нажмите «Выполнить», затем F7.

Последняя строка важна. Объединение возвращает структуру и код, но не значения. Если реквизит удалили и базу обновили, содержимое его поля удалено вместе с ним.

Если конфигурация в хранилище

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

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

Если пострадали данные или откат через .cf невозможен, восстанавливают базу целиком. Это возвращает и конфигурацию, и данные к моменту копии.

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

Выгрузка .dt

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

Файловая база

Остановите работу всех пользователей, переименуйте текущий файл 1Cv8.1CD (не удаляйте) и положите на его место файл из копии. Если копию делала встроенная обработка резервного копирования, восстанавливать удобнее ею же: в типовых конфигурациях на БСП она находится в Администрирование → Обслуживание.

Серверная база в MS SQL

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

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

RESTORE DATABASE [buh]
FROM DISK = N'D:\Backup\buh_full.bak'
WITH REPLACE, RECOVERY;

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

-- логические имена файлов смотрите командой RESTORE FILELISTONLY
RESTORE DATABASE [buh_restore]
FROM DISK = N'D:\Backup\buh_full.bak'
WITH NORECOVERY,
     MOVE N'buh' TO N'D:\SQL\buh_restore.mdf',
     MOVE N'buh_log' TO N'D:\SQL\buh_restore_log.ldf';

RESTORE LOG [buh_restore]
FROM DISK = N'D:\Backup\buh_log.trn'
WITH STOPAT = N'2026-10-05T18:59:00', RECOVERY;

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

Серверная база в PostgreSQL

Для дампа в формате custom:

pg_restore -U postgres -d buh --clean --if-exists /backup/buh.backup

Ключ --clean удаляет объекты текущей базы перед восстановлением. Если сомневаетесь, создайте пустую базу с другим именем и восстановите в неё.

Если копии нет, а база повреждена сбоем

После отключения питания файловая база может не открываться. Сделайте копию каталога базы и на копии запустите Администрирование → Тестирование и исправление в Конфигураторе. Для файловой базы есть и отдельная утилита chdbfl.exe в каталоге bin платформы. Работайте с копией: исправление может удалить повреждённые записи безвозвратно.

Как обновлять конфигурацию, чтобы откат не понадобился

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

• 💾 Копия перед каждым обновлением. Выгрузка .dt или бэкап СУБД с датой и номером релиза в имени файла.
• 🧪 Сначала тестовая база. Обновите копию, проведите пару документов, сформируйте основные отчёты. Только потом трогайте рабочую.
• 🪜 Только по цепочке. Типовые конфигурации обновляются последовательно, пропускать промежуточные релизы нельзя. Нужная цепочка указана в описании каждого релиза.
• 🔢 Проверка платформы. Номер версии платформы должен быть не ниже требуемого релизом.
• 🧩 Доработки — в расширения. Расширение отключается одной галочкой, и откат доработки не требует трогать основную конфигурацию.
• 🗂️ Архив релизов. Храните .cf каждой версии, установленной в базе.
• 🕑 Окно для работ. Обновляйте вечером или в выходной, когда пользователи не вводят документы.

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