Конфигурация БД не соответствует сохранённой в хранилище

📅 Опубликовано 17 августа 2026 г.

Коротко: Ошибка «Конфигурация базы данных не соответствует сохранённой в хранилище» означает расхождение трёх уровней метаданных 1С: хранилища, основной конфигурации и конфигурации базы данных. При подключении филиала к общему Git-репозиторию она возникает потому, что база филиала развёрнута из выгрузки Git (cf или XML), а хранилище ведёт собственный счётчик версий и не признаёт такую базу «своей». Штатное лечение — четыре шага в Конфигураторе: обновление конфигурации БД, отключение от хранилища, сверка версии, повторное подключение.

Ошибка — не поломка базы. Данные и регистры не затрагиваются: расходятся только метаданные. Восстановление не требует ни восстановления из резервной копии, ни перепроведения документов.
Git и хранилище конфигурации не синхронизируются сами по себе. Утилиты вида gitsync выгружают историю хранилища в репозиторий в одну сторону; обратной автоматической загрузки коммитов в хранилище нет.
Причина №1 у филиалов — подключение к хранилищу базы, восстановленной из dt-файла или собранной из cf-сборки, минуя штатное «Получить конфигурацию из хранилища».
Ключ к диагностике — три числа: номер версии хранилища, версия, с которой связана база, и признак «конфигурация БД отличается от основной» в заголовке Конфигуратора (знак «*» и пункт «Обновить конфигурацию базы данных»).
Регламент вместо героизма: один контур разработки = одно хранилище + одна ветка Git; филиал разворачивается только по документированной процедуре, описанной ниже.

Что означает сообщение «Конфигурация базы данных не соответствует сохранённой в хранилище»?

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

Уровень	Где хранится	Как посмотреть	Чем приводится в соответствие
Хранилище конфигурации	Отдельная база хранилища на сервере или в сетевой папке	Конфигуратор → Конфигурация → Хранилище конфигурации → История хранилища	Команда «Поместить в хранилище» / «Обновить конфигурацию из хранилища»
Основная конфигурация	Внутри информационной базы, редактируемая копия	Конфигуратор → Конфигурация → Открыть конфигурацию (звёздочка в заголовке = есть изменения)	Загрузка из файла, объединение, получение из хранилища
Конфигурация базы данных	Внутри информационной базы, рабочая копия для пользователей	Конфигурация → Конфигурация базы данных → Сравнить, объединить	Кнопка «Обновить конфигурацию базы данных» (F7)

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

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

Почему ошибка появляется именно при подключении филиала к общему Git-репозиторию?

Схема «общий Git-репозиторий + хранилище конфигурации» строится так: центральный офис разрабатывает в хранилище, конвертер (чаще всего gitsync на OneScript или выгрузка через EDT) переносит каждую версию хранилища в коммит Git, а сборочный конвейер собирает из репозитория файл поставки cf или пакет XML-файлов. Филиал получает результат сборки — и именно здесь ломается логика привязки.

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

Задержка конвейера. Между помещением версии в хранилище и появлением собранного cf в артефактах проходит время сборки. Если за это время центральный офис поместил ещё две версии, филиал разворачивает уже неактуальный слепок.
Разные ветки. Хранилище всегда линейно — это одна ветка по определению. Git — нет. Сборка из ветки develop, подключаемая к хранилищу, которое живёт по релизной ветке, гарантированно даёт расхождение.
Ручные правки на местах. Филиал добавил в свою копию печатную форму «под себя», не поместив её в хранилище. Формально база изменена, фактически — история хранилища об этом не знает.

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

Какие семь причин вызывают расхождение конфигурации с хранилищем?

1. Конфигурация базы данных не обновлена после получения изменений

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

2. База развёрнута из dt или cf в обход хранилища

Администратор филиала выгрузил базу центрального офиса в dt, загрузил у себя и подключился к хранилищу. Идентификатор хранилища и номер версии в загруженной базе относятся к другой физической базе хранилища либо не относятся ни к чему. Требуется отключение от хранилища с очисткой привязки и повторное подключение с получением конфигурации из хранилища.

3. Локальные изменения, не помещённые в хранилище

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

4. Сборка собрана из другой ветки Git

Конвейер собрал cf из ветки с незавершённой задачей, а хранилище филиала синхронизировано с релизной веткой. Внешне конфигурация «почти такая же», по факту различаются десятки объектов. Проверяется сравнением номера версии хранилища с меткой сборки в артефакте. Правильный порядок построения такой связки описан в разборе того, как выстроить хранение конфигурации 1С в Git и CI/CD.

5. Незавершённое динамическое обновление

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

6. Разные версии платформы и режимы совместимости

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

7. Восстановление базы из резервной копии «задним числом»

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

Причина	Ключевой признак	Действие	Трудозатраты специалиста
Не обновлена конфигурация БД	Звёздочка в заголовке, активен пункт «Обновить конфигурацию базы данных»	F7 в монопольном режиме	Зависит от объёма реструктуризации
Разворот из dt/cf	Подключение проходит, захват объектов запрещён	Отключение от хранилища + повторное подключение	Зависит от размера конфигурации
Локальные доработки	Отчёт сравнения показывает изменённые объекты	Выгрузка правок, захват, помещение	Зависит от числа изменённых объектов
Ветка Git не та	Метка сборки не совпадает с версией хранилища	Пересборка из релизной ветки	Зависит от длительности сборки в конвейере
Незавершённое обновление	Ошибка реструктуризации в журнале регистрации	Блокировка сеансов, повтор обновления	Зависит от объёма незавершённых изменений
Разные версии платформы	Ошибка при открытии конфигурации хранилища	Выравнивание версии платформы по всему контуру	2–6 часов
Откат из бэкапа	Номер версии базы меньше номера версии хранилища	Получение конфигурации из хранилища	30–90 минут

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

Как исправить ошибку: пошаговый порядок действий в Конфигураторе

Порядок универсален и не зависит от того, какая из семи причин сработала. Начинайте с резервной копии — на реструктуризации это единственная страховка.

Сделайте резервную копию. Для файловой базы — копия каталога, для клиент-серверной — средствами СУБД. Выгрузка в dt на этом этапе не подходит: она может завершиться ошибкой ровно из-за расхождения метаданных.
Зафиксируйте три числа. Номер последней версии в истории хранилища (Конфигурация → Хранилище конфигурации → История хранилища), номер версии, с которой связана база (там же, в свойствах подключения), и наличие звёздочки в заголовке Конфигуратора. Эти три значения определяют дальнейший маршрут.
Снимите блокировку от пользователей. Администрирование → Блокировка установки соединений с информационной базой, затем завершение активных сеансов. Динамическое обновление при живых сеансах — источник причины №5.
Выполните «Обновить конфигурацию базы данных» (F7). Если платформа предложила принять изменения структуры — согласитесь и дождитесь окончания реструктуризации, не прерывая процесс.
Если ошибка сохраняется — сравните конфигурации. Конфигурация → Сравнить, объединить с конфигурацией из файла, где файл — выгрузка cf текущей версии хранилища. Отчёт о сравнении покажет ровно те объекты, из-за которых база считается «чужой».
Сохраните локальные доработки. Все объекты, которых нет в хранилище, выгрузите в отдельный cf-файл или в файлы XML. Без этого шага следующий пункт уничтожит работу филиала.
Отключитесь от хранилища и подключитесь заново. Конфигурация → Хранилище конфигурации → Отключиться от хранилища, затем Подключиться к хранилищу с установленным флагом получения конфигурации из хранилища. База получит актуальную версию и корректную привязку.
Верните доработки штатным путём. Захватите нужные объекты, объедините с сохранённым файлом, поместите изменения в хранилище с внятным комментарием.

Для массового обновления баз филиалов шаг с обновлением конфигурации базы данных выполняют пакетным запуском Конфигуратора — это единственная команда, которую имеет смысл вынести в скрипт обслуживания:

1cv8.exe DESIGNER /S сервер\база /N админ /P пароль /UpdateDBCfg -Server /DisableStartupMessages

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

Найдите специалиста для решения этой задачи на koderion.ru