Оборвалось обновление 1С: что случится с данными и как вернуть базу

Данные после сбоя обновления чаще всего целы, если у вас клиент-серверная база : СУБД откатывает незавершённую транзакцию. В файловой базе риск выше. Файл 1Cv8.1CD при аварийном обрыве может остаться в неконсистентном состоянии, и тогда спасает только резервная копия.

Исход зависит от того, на каком этапе оборвалось обновление, где лежит база и что именно упало: сервер, сеть, питание, сам процесс 1С. Ниже разобрано, что происходит под капотом, как понять, в каком состоянии база, и что делать по шагам.

Из каких этапов состоит обновление и где можно потерять данные

Обновление не одна операция, а цепочка. Сбой на разных звеньях даёт разные последствия.

1. Загрузка новой конфигурации. Конфигуратор объединяет файл релиза с конфигурацией поставщика. Пользовательские данные на этом этапе не трогаются, меняется только описание объектов.
2. Обновление конфигурации базы данных. Здесь платформа сверяет структуру таблиц с новой конфигурацией и выполняет реструктуризацию: добавляет поля, меняет типы, перестраивает индексы. Это самый опасный этап.
3. Обработчики обновления. При первом входе в обновлённую базу выполняются процедуры, которые переносят данные в новые структуры, заполняют новые реквизиты, пересчитывают итоги.
4. Отложенные обработчики. Часть работы уходит в фон и может идти несколько дней после обновления.

Для сравнения рисков:

Почему реструктуризация опаснее всего

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

На крупных базах этап занимает десятки минут, а иногда часы. Чем он дольше, тем больше окно, в которое может попасть сбой.

Что бывает при аварийном завершении: типичные сценарии

Сбой сбою рознь. Вот что встречается на практике.

• ⚡ Отключили питание. Файловая база может получить битые страницы. SQL-сервер при старте прогонит журнал и откатит незавершённое.
• 🖥️ Зависла или упала служба сервера 1С. Сеансы обновления сброшены, блокировка на базе может остаться висеть.
• 🌐 Пропала сеть у пользователя, который обновлял по сети. Конфигуратор потерял связь, но сервер мог продолжить операцию или откатить её.
• 🔒 Закончилось место на диске. Частая причина: реструктуризация требует свободного места под временные копии таблиц.
• ❌ Убили процесс вручную из диспетчера задач, потому что «долго висит». Для файловой базы это худший вариант.
• 🧱 Ошибка в обработчике обновления. Платформа не падает, но выдаёт сообщение и останавливается на полпути.

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

Что остаётся после сбоя

Возможны четыре состояния:

1. База не изменилась. Откат прошёл полностью, старая версия работает.
2. База осталась в промежуточном состоянии. Конфигурация уже новая, а структура таблиц ещё старая или смешанная.
3. База повреждена на уровне файла или таблиц.
4. База в порядке, но висят блокировки или монопольный режим.

Определить, какое из состояний ваше, помогает диагностика ниже. Сначала о различиях между типами баз.

Файловая и клиент-серверная база: как различаются последствия

От способа хранения зависит почти всё: надёжность отката, способы восстановления, скорость.

Файловая база

Все данные лежат в одном файле 1Cv8.1CD. Транзакционности на уровне СУБД нет: платформа сама пишет в файл. Если процесс оборвали посреди записи, файл теряет целостность.

Последствия бывают такие:

• при запуске появляется сообщение о повреждении структуры, ошибки чтения таблиц;
• база открывается, но часть документов не проводится или не открывается;
• база не открывается вовсе.

Для файловых баз резервная копия перед обновлением не рекомендация, а единственная гарантия. Скопируйте каталог базы целиком, пока никто не работает .

Клиент-серверная база (PostgreSQL, MS SQL)

Операции идут через СУБД, и незавершённая транзакция откатывается автоматически. Реструктуризация выполняется транзакциями, поэтому вероятность получить «полупреобразованные» таблицы заметно ниже.

Но у сервера свои риски:

• переполнился журнал транзакций, и операция остановилась;
• заняты ресурсы: блокировки таблиц удерживает зависший сеанс;
• при выключенном или неправильно настроенном резервировании откатиться нечем, если проблема проявилась позже.

Как понять, в каком состоянии база после инцидента

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

Шаг 1. Сохраните то, что есть

Остановите сервер 1С или закройте все сеансы. Скопируйте каталог файловой базы или сделайте бэкап базы на SQL-сервере. Даже повреждённая копия пригодится: по ней можно искать причину и пробовать восстановление, не рискуя оригиналом.

Шаг 2. Выясните, что показывает журнал

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

Шаг 3. Посмотрите на сообщение при запуске

Текст ошибки подскажет этап:

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

Шаг 4. Проверьте целостность

Для файловой базы есть утилита chdbfl, она лежит в каталоге платформы. Запускайте её только на копии базы. Режим исправления вносит изменения, и повторить его нельзя.

В Конфигураторе есть штатное средство: пункт «Администрирование», затем «Тестирование и исправление». Для проверки без изменений выберите режим «Тестирование без исправления». Если он ничего не нашёл, а база всё равно не работает, проблема скорее в конфигурации или блокировках.

Порядок восстановления: что делать и в какой последовательности

Идите от самого щадящего способа к самому радикальному. Каждый следующий шаг оправдан, только если предыдущий не помог.

Способ 1. Завершить обновление

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

Условие одно: свободное место на диске. Для крупной базы закладывайте запас, сопоставимый с её размером.

Способ 2. Снять зависшие блокировки

Если база цела, но не пускает:

1. Завершите все сеансы пользователей в консоли серверов 1С или через список активных пользователей.
2. На сервере проверьте, не остались ли процессы 1cv8 или rphost, и корректно завершите их.
3. Для файловой базы убедитесь, что рядом с файлом базы нет залипшего файла блокировки от завершённого сеанса, и только потом удаляйте его.

Способ 3. Исправить структуру штатными средствами

Запустите «Тестирование и исправление» на копии базы. Включайте только нужные режимы: реструктуризация таблиц, проверка логической целостности. Затем снова обновите конфигурацию базы.

Способ 4. Восстановить из резервной копии

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

Что вы теряете: все изменения, внесённые между копией и сбоем. Если обновление шло ночью или в нерабочее время, потерь обычно нет.

Способ 5. Выгрузить и загрузить данные

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

Выгрузка работает только если база читается целиком. Из сильно повреждённой её сделать не получится.

Способ 6. Специалисты по восстановлению

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

Что проверить в базе после восстановления

Даже если база открылась, не возвращайте её сразу в работу. Пройдите короткий чек-лист.

Что сверить с цифрами до обновления

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

Как не попасть в эту историю: правила безопасного обновления

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

1. Копия перед каждым обновлением. Для файловой базы это копия каталога, для SQL бэкап базы. Проверьте, что копия открывается.
2. Свободное место. Свободно должно быть не меньше размера базы, лучше полтора-два.
3. Закрытые сеансы. Все пользователи вышли, регламентные задания остановлены, сервер не перезагружается по расписанию в это время.
4. Источник бесперебойного питания на сервере с файловой базой, особенно в небольших офисах.
5. Тест на копии. Крупное обновление сначала прогоните на копии базы и оцените время.
6. Рабочее окно. Выбирайте момент, когда у вас есть запас времени на откат: не конец отчётного периода.
7. Не прерывайте процесс. Если обновление «висит» час, это ещё не повод убивать его. Смотрите нагрузку на диск и процессор: если они есть, платформа работает.

Решить, как действовать в вашем случае, поможет короткое дерево.

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