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