Как вернуть потерянный код конфигурации в 1С 8.3

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

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

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

Где вообще хранится код: резервные копии и три конфигурации

Прежде чем что-то восстанавливать, поймите, где код мог сохраниться. Вариантов больше, чем кажется:

• 🗄️ Выгрузка информационной базы — файл .dt. Содержит и конфигурацию, и данные. Путь в Конфигураторе: Администрирование → Выгрузить информационную базу.
• 🧩 Выгрузка конфигурации — файл .cf. Только метаданные и код, без данных. Путь: Конфигурация → Сохранить конфигурацию в файл.
• 💾 Копия файловой базы — сам файл 1Cv8.1CD. Для файлового варианта это полный слепок: и код, и данные.
• 🗃️ Бэкап СУБД — для клиент-серверного варианта резервная копия SQL Server или PostgreSQL. Содержит всё, включая конфигурацию базы данных.
• 📚 Хранилище конфигурации — если разработка шла через него, там лежит вся история версий каждого модуля.
• 🌿 Git / выгрузка в файлы — если проект ведётся в 1C:EDT или код периодически выгружался в XML-файлы, модули хранятся как обычный текст под версионным контролем.

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

Откат к конфигурации базы данных

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

Чтобы отменить все несохранённые правки основной конфигурации и вернуть её к рабочему состоянию:

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

После этого основная конфигурация станет точной копией той, по которой работают пользователи.

Операция затирает все правки основной конфигурации, которые вы не успели обновить в базе. Если среди них было что-то нужное — сначала сохраните текущую основную в .cf (Конфигурация → Сохранить конфигурацию в файл), а уже потом откатывайтесь. Тогда вы сможете выборочно вернуть полезные куски сравнением.

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

Журнал регистрации: найти момент и восстановить базу на него

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

Откройте Администрирование → Журнал регистрации и найдите последние сеансы до сбоя или запуск Конфигуратора, после которого всё сломалось. Эта отметка времени и есть ориентир для выбора резервной копии.

Для клиент-серверной базы одного .dt может не быть, но есть журнал транзакций СУБД. Он позволяет восстановить базу на точный момент времени (point-in-time), а не только на время последнего полного бэкапа:

• SQL Server — полный бэкап восстанавливают с WITH NORECOVERY, затем накатывают цепочку логов до нужной секунды через RESTORE LOG ... WITH STOPAT.
• PostgreSQL — восстановление из базового бэкапа плюс WAL-архив до заданной точки (recovery target time).

Вернуть код через сравнение и объединение конфигураций

Это рабочая лошадка восстановления. У вас есть старая копия кода в виде .cf (или развёрнутой в сторонке базы), а в текущей что-то потеряно. Нужно перенести обратно только утраченное, не откатывая всё целиком.

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

1. Конфигурация → Сравнить, объединить с конфигурацией из файла.
2. Укажите старый .cf (или выгрузите .cf из резервной базы и возьмите его).
3. В окне сравнения 1С покажет, чем конфигурации отличаются — по объектам и построчно по коду модулей.
4. Снимите флажки со всего и отметьте только те объекты и модули, которые нужно вернуть.
5. Настройте правила объединения (брать из файла / оставлять текущее) и выполните объединение.
6. Сохраните основную конфигурацию и обновите базу через F7.

Отдельно стоит отчёт Конфигурация → Сравнить конфигурации: он не меняет код, а показывает различия построчно. Удобно распечатать или сохранить, чтобы руками перенести небольшой фрагмент.

Если потеряно изменение в типовом объекте, который вы не переписывали с нуля, его исходный вид вернёт сравнение с конфигурацией поставщика: Конфигурация → Поддержка → Сравнить, объединить с конфигурацией поставщика. Так восстанавливают заводской код процедуры, случайно испорченной правкой.

Один важный нюанс при объединении. Если конфигурация стоит на поддержке с запретом изменений, перенести правки в защищённые объекты не получится, пока не включена возможность редактирования. Проверьте режим в Конфигурация → Поддержка → Настройка поддержки: там же видно, какие объекты сняты с поддержки, а какие заблокированы замком. Снимать защиту ради восстановления стоит только с тех объектов, что вы и так дорабатывали, — иначе потом будет сложнее обновляться на новые релизы типового решения.

Хранилище конфигурации и выгрузка в файлы

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

• Подключитесь к хранилищу: Конфигурация → Хранилище конфигурации → Открыть хранилище конфигурации.
• Откройте историю: Конфигурация → Хранилище конфигурации → История хранилища.
• Найдите версию, в которой нужный модуль был цел, и получите её.

Так можно вытащить состояние объекта на любой момент, когда его помещали в хранилище, — даже если в рабочей базе он давно испорчен.

Второй современный источник — выгрузка конфигурации в файлы и Git. Если проект ведётся в 1C:EDT, весь код уже лежит в репозитории как текстовые файлы, и восстановление сводится к git checkout нужного коммита. Если EDT не используется, но вы периодически делали Конфигурация → Выгрузить конфигурацию в файлы, модули сохранены как XML и легко читаются в любом текстовом редакторе. Найдите в выгрузке файл нужного модуля — его содержимое и есть ваш код.

Когда помогут поставщик конфигурации и партнёр 1С

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

• Типовой код (из коробочного решения) восстанавливается из конфигурации поставщика — см. раздел про сравнение выше. Отдельно у поставщика его просить не нужно, эталон уже лежит в вашей базе.
• Ваши доработки в конфигурации поставщика нигде на стороне нет — их знает только ваша база и ваши бэкапы. Поэтому так важны хранилище и выгрузки.

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

Для внешних печатных форм и обработок (.epf, .erf) есть ещё один источник: сами файлы обработок, разложенные по рабочим местам пользователей и в каталогах дополнительных отчётов. Код внутри них никуда не делся.

Ручное восстановление модуля по фрагментам

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

• 📄 Развёрнутые копии. Любая старая база, демо-база, копия на ноутбуке разработчика — источник. Разверните её отдельно и сравните конфигурации.
• 🔎 Выгрузка в файлы из любой копии. Выгрузите конфигурацию в XML и ищите нужный метод по имени — текст процедур хранится как есть.
• 🧾 Техническое задание и переписка. Постановка, письма, тикеты часто содержат логику и даже куски кода, которые согласовывали.
• 🖨️ Результаты работы. Если модуль формировал печатную форму или отчёт, по готовому результату реконструируется алгоритм расчёта.

Чтобы быстро снять дамп кода из любой доступной копии для поиска, пригодится пакетный запуск Конфигуратора:

"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" DESIGNER /F "D:\base" /N "Администратор" /P "" /DumpCfg "D:\backup\copy.cf"

Для клиент-серверной базы вместо /F "путь" указывают /S "сервер\база". Выгрузку всей информационной базы в .dt из командной строки делает ключ /DumpIB. Остальные параметры смотрите в справке: запустите 1cv8.exe /? или откройте раздел пакетного режима в документации платформы.

Как больше не терять код

Восстановление — всегда стресс и часы работы. Дешевле выстроить защиту заранее:

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

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