Как откатить хранилище конфигурации 1С

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

Выбор способа зависит от ситуации: нужно ли вернуть один объект, всю конфигурацию целиком или отменить действия конкретного разработчика. Также важно, есть ли у вас резервная копия хранилища (файл 1cv8ddb или папка с файлами хранилища) и сохранились ли выгрузки конфигурации в формате .cf нужных версий.

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

Как устроено хранилище и почему откат неочевиден

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

Ключевой момент: версии в хранилище аддитивны. Платформа позволяет получить любую версию конфигурации на чтение (через «Конфигурация → Хранилище конфигурации → Отчет по истории» с выбором версии и сохранением в файл), но не позволяет удалить или «перемотать» версии штатными средствами конфигуратора. Поэтому под «откатом» обычно понимают одно из трёх действий: замену файлов хранилища резервной копией, загрузку в хранилище старой версии конфигурации поверх текущей или точечный возврат отдельных объектов.

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

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

Второй шаг — определить целевую версию. Откройте отчёт по истории хранилища («Конфигурация → Хранилище конфигурации → Отчет по истории»), найдите версию, до которой нужно откатиться, и зафиксируйте её номер. Уточните у команды, какие помещённые после неё изменения нужно сохранить — это определит объём ручной работы после отката.

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

Способ 1: восстановление хранилища из резервной копии

Самый чистый откат — вернуть хранилище целиком из копии, сделанной в момент, когда оно было в нужном состоянии. Это подходит, если версионный резервный регламент настроен (например, ежедневное копирование папки хранилища) и целевая точка совпадает с моментом копирования.

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

Ограничение способа очевидно: вы получите состояние на момент копии, а не на произвольную версию. Если копия делалась раз в сутки, а ошибочные изменения помещались в течение дня, откат затронет и «хорошие» доработки за этот период. Также помните, что локальные базы разработчиков, уже обновившиеся из хранилища, будут содержать более новые версии — им потребуется переподключение или обновление с осторожностью.

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

Способ 2: загрузка в хранилище конфигурации нужной версии

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

Последовательность такая. В отчёте по истории хранилища выберите целевую версию и сохраните её конфигурацию в файл .cf (в отчёте есть возможность получить конфигурацию выбранной версии). Затем в рабочей базе разработчика, подключённой к хранилищу, выполните захват корня конфигурации с рекурсивным захватом всех объектов, загрузите конфигурацию из сохранённого файла .cf («Конфигурация → Загрузить конфигурацию из файла») и поместите изменения в хранилище с понятным комментарием, например «Откат к версии N».

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

Сравнение способов отката

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

Подходит, когда есть копия на нужный момент. Быстро и полностью откатывает историю, но теряются все изменения после момента копирования.

Загрузка версии из .cf

Универсальный способ без копии хранилища. История сохраняется, но требуется захват всех объектов и аккуратное помещение; старые версии остаются в истории.

Точечный возврат объектов

Подходит, когда ошибочна одна-две доработки. Минимальные потери, но трудоёмко при большом числе затронутых объектов.

Способ 3: точечный возврат отдельных объектов

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

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

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

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

Отмена захвата и работа с локальными базами после отката

Частая сопутствующая задача — отменить захват объектов, который мешает откату. Администратор хранилища может отменить чужой захват через «Конфигурация → Хранилище конфигурации → Отменить захват» с выбором пользователя, чей захват снимается. Учтите: отмена захвата не возвращает объект к прежнему содержимому, она лишь освобождает блокировку; непомещённые изменения другого разработчика при этом могут быть потеряны для хранилища.

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

Проверка результата и типичные ошибки

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

Контрольные точки

Как проверить результат

Номер последней версии в отчёте по истории

Норма

Версия соответствует целевой точке отката или содержит комментарий об откате

Тревожный признак

Последняя версия — ошибочная, откат не применился

Проверка конфигурации в конфигураторе

Норма

Проверка завершается без критических ошибок

Тревожный признак

Ошибки ссылочной целостности после загрузки старой версии

Обновление тестовой базы из хранилища

Норма

Обновление проходит, база запускается, ключевые функции работают

Тревожный признак

Конфликты версий, ошибки реструктуризации

Сохранённые доработки коллег

Норма

Нужные изменения перенесены и помещены заново

Тревожный признак

Доработки потеряны вместе с откаченными версиями

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

Можно ли удалить отдельные версии из истории хранилища?

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

Что делать, если хранилище повреждено и не открывается?

Сначала попробуйте восстановить его из последней резервной копии. Если копии нет, хранилище как базу данных можно попытаться обработать утилитой тестирования и исправления (chdbfl для файловых баз), но результат не гарантирован. На будущее настройте регулярное копирование папки хранилища — это единственная надёжная защита от его повреждения.

Откатится ли база данных вместе с хранилищем?

Нет. Хранилище содержит только конфигурацию и её историю, но не данные информационных баз. Откат хранилища не затрагивает рабочие базы: их конфигурации изменятся только после явного обновления из хранилища, а данные не меняются вовсе (кроме реструктуризации при обновлении, если структура метаданных отличается).

Как откатиться, если ошибочную версию поместили давно и поверх неё много изменений?

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

Нужны ли особые права для отката хранилища?

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