Ошибка «сбой промежуточного сохранения метаданных» чаще всего возникает в платформе 1С:Предприятие в момент обновления конфигурации базы данных, когда платформа не может зафиксировать промежуточное состояние структуры метаданных и прерывает процесс. Внешне это выглядит так: обновление конфигурации запускается, проходит часть этапов, а затем останавливается с сообщением о сбое, после чего база может оказаться в незавершённом состоянии обновления. Проблема серьёзная, потому что без корректного завершения обновления метаданных прикладное решение обычно не запускается в штатном режиме.
Точный текст сообщения и контекст его появления зависят от версии платформы и режима работы базы (файловый или клиент-серверный). Поэтому первое действие — не искать «универсальную кнопку исправления», а зафиксировать, на каком этапе произошёл сбой: при реструктуризации таблиц, при сохранении конфигурации или при динамическом обновлении. От этого напрямую зависит порядок восстановления.
Что означает эта ошибка
При обновлении конфигурации платформа 1С изменяет структуру базы данных: добавляет и изменяет таблицы, индексы, поля, переносит данные между старыми и новыми структурами. Этот процесс идёт поэтапно, и на промежуточных шагах платформа сохраняет текущее состояние метаданных. Сбой промежуточного сохранения означает, что один из этих шагов завершился неудачно — платформа не смогла записать промежуточное состояние.
Последствия различаются. Иногда обновление просто откатывается, и база остаётся в исходном состоянии. В более тяжёлых случаях база «зависает» между версиями: конфигурация базы данных частично обновлена, а при попытке запуска появляется требование завершить обновление, которое снова падает с той же ошибкой.
Типичные причины сбоя
Единой причины у этой ошибки нет, но практика показывает несколько повторяющихся сценариев. Ни один из них нельзя считать подтверждённым без проверки — это направления диагностики, а не готовый диагноз.
- 🔒 Активные сеансы пользователей — обновление запущено при открытых соединениях с базой, и платформа не получила монопольный доступ к данным.
- 💾 Нехватка свободного места на диске с базой или с временными файлами — реструктуризация больших таблиц требует заметного объёма.
- 🧩 Повреждение данных или структуры — ошибки в конкретной таблице прерывают реструктуризацию на промежуточном этапе.
- ⚙️ Несовместимость версий — конфигурация рассчитана на другой релиз платформы, либо обновление выполняется через пропущенные промежуточные версии.
- 🛡️ Вмешательство антивируса или прав доступа — блокировка файлов базы или временных каталогов сторонним ПО.
Для клиент-серверного варианта добавляются свои факторы: ограничения на стороне СУБД, нехватка прав у учётной записи сервера, тайм-ауты длинных транзакций. В этом случае диагностику стоит вести совместно с администратором сервера баз данных.
Обязательная подготовка перед любыми действиями
⚠️ Внимание: любые действия с базой, где произошёл сбой обновления, начинайте только после создания резервной копии. Для файловой базы — скопируйте файл1Cv8.1CDцеликом, для клиент-серверной — сделайте выгрузку средствами СУБД или файл.dtчерез конфигуратор. Без копии ошибочное действие может сделать восстановление невозможным.
Резервная копия нужна не «на всякий случай», а как точка возврата: если повторное обновление тоже завершится сбоем, но уже на другом этапе, вы сможете откатиться и попробовать иной путь. Храните копию на другом диске или сетевом ресурсе, а не рядом с рабочей базой.
Также зафиксируйте текущее состояние: версию платформы, релиз конфигурации до обновления и целевой релиз. Эта информация понадобится, если придётся обращаться к документации поставщика конфигурации или в поддержку.
Пошаговая диагностика и устранение
Порядок действий построен от безопасных и обратимых проверок к более серьёзным процедурам. Не перескакивайте через шаги: простые причины встречаются не реже сложных.
Шаг 1. Завершите все сеансы. Закройте все запущенные клиенты 1С, проверьте фоновые задания и при клиент-серверном режиме — список активных соединений в консоли кластера. Обновление конфигурации базы данных запускайте при гарантированно монопольном доступе.
Шаг 2. Проверьте свободное место и права. Убедитесь, что на диске с базой и в каталоге временных файлов достаточно свободного объёма, а у учётной записи есть полные права на каталог базы. Временно проверьте, не блокирует ли файлы антивирус: добавьте каталог базы в исключения по документации вашего антивирусного решения.
Шаг 3. Выполните тестирование и исправление. В конфигураторе откройте Администрирование → Тестирование и исправление и запустите проверку в режиме без исправления, чтобы сначала увидеть перечень ошибок. Если обнаружены повреждения, повторите с исправлением — но только на копии базы или после свежей резервной копии.
Шаг 4. Повторите обновление. После устранения найденных проблем снова запустите обновление конфигурации базы данных и наблюдайте, на каком этапе оно проходит или падает.
☑️ Перед повторным обновлением конфигурации
Если сбой повторяется
Когда обновление снова останавливается с тем же сообщением, нужен более глубокий анализ. Откройте технологический журнал платформы и журнал регистрации — там фиксируется, какая именно таблица или операция вызвала сбой. Настройка технологического журнала описана в официальной документации 1С для вашей версии платформы.
Для файловой базы рабочим приёмом часто оказывается выгрузка базы в файл .dt и загрузка в новую пустую базу, после чего обновление выполняется уже там. Этот способ устраняет часть внутренних повреждений файловой структуры, но при больших объёмах требует времени и дискового пространства.
⚠️ Внимание: не пытайтесь «пропустить» проблемный этап редактированием структуры вручную или запуском обновления с отключёнными проверками — такие действия могут привести к рассинхронизации конфигурации и данных, после которой база перестанет открываться вовсе.
Для клиент-серверных баз аналогичную роль играет проверка целостности средствами СУБД и анализ её журналов ошибок. Здесь корректнее привлечь администратора СУБД: действия напрямую в базе данных в обход платформы 1С не поддерживаются и опасны.
Сравнение сценариев восстановления
| Сценарий | Когда применять | Риски |
|---|---|---|
| Повторное обновление после завершения сеансов | Сбой при активных пользователях | Минимальные |
| Тестирование и исправление | Подозрение на повреждение данных | Средние, только после копии |
| Выгрузка/загрузка через .dt | Повторяющийся сбой в файловой базе | Средние, требует времени и места |
| Анализ технологического журнала | Непонятный этап сбоя | Без риска, только диагностика |
| Обращение в поддержку поставщика | Несовместимость релизов, специфика конфигурации | Минимальные |
Профилактика повторения ошибки
Большинство сбоев промежуточного сохранения метаданных предотвращаются дисциплиной обновлений, а не инструментами восстановления. Обновляйте конфигурацию последовательно, через рекомендованные поставщиком промежуточные релизы, и всегда — в окне без работающих пользователей.
Полезно вести простой регламент: перед каждым обновлением — копия, проверка свободного места, тестирование на копии базы для крупных переходов. Тестовое обновление на копии занимает время, но показывает проблемные этапы заранее, без риска для рабочих данных.
Что делать, если база требует завершить обновление, но оно не проходит
Откройте конфигуратор и проверьте, доступен ли пункт обновления конфигурации базы данных повторно. Если платформа сообщает о незавершённом обновлении, не запускайте прикладной режим. Восстановите базу из резервной копии, сделанной до первого сбоя, устраните причину (сеансы, место, повреждения) и только затем повторите обновление с начала. Если копии нет — сначала выполните тестирование и исправление и выгрузку .dt, чтобы зафиксировать данные в переносимом виде.
Часто задаваемые вопросы
Можно ли продолжать работать в базе после такого сбоя?
Если обновление откатилось полностью — обычно да, но сначала убедитесь, что база открывается без сообщений о незавершённом обновлении. Если платформа требует завершить обновление, работать в прикладном режиме нельзя до устранения проблемы.
Поможет ли просто перезагрузка сервера или компьютера?
Перезагрузка снимает зависшие сеансы и блокировки файлов, поэтому как часть подготовки она полезна. Но сама по себе она не устраняет повреждения данных или несовместимость версий — ошибка вернётся при повторном обновлении.
Опасно ли тестирование и исправление для данных?
Режим исправления изменяет данные, поэтому запускать его нужно только при наличии резервной копии. Разумная практика — сначала прогнать проверку без исправления и оценить список найденных ошибок.
Сбой возникает только при динамическом обновлении — что делать?
Динамическое обновление имеет больше ограничений и чувствительнее к активным сеансам. Откажитесь от него в пользу обычного обновления с монопольным доступом — это надёжнее и требование большинства поставщиков конфигураций.
Когда стоит обращаться в поддержку 1С или франчайзи?
Если сбой повторяется после всех проверок, если технологический журнал указывает на конкретную таблицу, а исправление не помогает, или если конфигурация сильно доработана — самостоятельное вмешательство становится рискованным, и лучше передать диагностику специалистам.