Обновление Accounting упало: вернуть копию, не жать «повторить» на полпути

Короткий ответ

Если обновление конфигурации/платформы 8.3 оборвалось на Accounting, не продолжайте установку поверх полуприменённой реструктуризации и не запускайте пользователей «вдруг пройдёт». Зафиксируйте сообщение, убедитесь что есть проверенная копия до обновления, верните базу из этой копии, разбор ошибки — на копии. Частично обновлённая информационная база — это не «ещё одна попытка того же cfu», а риск расхождения метаданных и данных.

Клиент-сервер: SRV-1C + SQL01 (MSSQLSERVER). Файловая: каталог с 1Cv8.1CD. Откат SQL — restore в согласованное состояние, не ручные DELETE из таблиц конфигурации.

Симптомы и как отличить

Типичная картина:

• конфигуратор остановился на реструктуризации, база больше не открывается предприятием;
• «конфигурация базы данных не соответствует сохранённой»;
• места на диске SQL01 не хватило на время обновления;
• сеансы выгнали не всех, обмен писал во время cfu.

Отличия:

Подготовка, которой не хватило: как подготовиться к обновлению.

Возможные причины

1. Нет монопольного режима: сеанс/регламент держал объекты.
2. Закончилось место под данные или журнал транзакций на время реструктуризации.
3. Timeout SQL, блокировка, убитый сеанс конфигуратора.
4. CFU не от той версии конфигурации.
5. Обновили платформу и конфигурацию одним вечером без теста.
6. Права SQL-учётки 1С ниже нужных на alter.
7. Редко: повреждение до обновления, которое вскрылось на реструктуризации.

Диагностика

1. Что именно обновляли

Платформа 8.3 / конфигурация / и то и другое. Номер релиза «с» и «на». Окно, кто выгонял сеансы.

2. Есть ли точка отката

• SQL: full backup Accounting до начала, не только nightly вчера, если утром уже писали.
• Файловая: копия каталога до cfu.
• DT-выгрузка, если делали.

Если копии нет — снимите сейчас копию аварийного состояния (MDF/LDF или 1CD), даже битого, затем решайте. Не overwrite.

3. Журналы

Журнал регистрации 1С, окно конфигуратора, SQL ERRORLOG, место на томах.

SELECT name, state_desc, user_access_desc, log_reuse_wait_desc
FROM sys.databases WHERE name = N'Accounting';

log_reuse_wait_desc = ACTIVE_TRANSACTION / LOG_BACKUP — обновление могло упереться в log. См. журнал транзакций.

4. Сеансы

Кластер должен быть без пользователей перед повторной попыткой на тесте, не на проде.

Решение

Сценарий A. Есть full backup / копия каталога до обновления

1. Никого в базу.
2. Сохраните аварийную копию «после сбоя» отдельно.
3. Восстановите копию «до» в Accounting (SQL: штатный restore цепочки, см. restore; файловая — подмена каталога на проверенную копию).
4. Пользователи работают на старом релизе.
5. На отдельной базе Accounting_updtest воспроизведите обновление, снимите ошибку, только потом новое окно.

Сценарий B. Реструктуризация упала из-за диска

Откат по копии, расширение диска, повтор на тесте. Добивать прод при 0 байт свободно — путь к Suspect.

Сценарий C. Конфигуратор предлагает продолжить

Только если вы точно на копии и понимаете шаг. На проде после обрыва питания — нет. Продолжение «ещё раз тот же cfu» на полуреструктурированной базе часто делает хуже.

Сценарий D. Обновили только платформу, конфигурация старая

Это не откат базы: верните клиентам совместимую сборку 8.3 или завершите плановое обновление клиентов. Базу SQL не restore-ьте из-за ярлыков.

Контур Accounting: окно, место и запрет «ещё одна попытка»

Перед любым повтором на тесте проверьте, что на SQL01 после отката Accounting в ONLINE, log_reuse_wait_desc не LOG_BACKUP, и есть full свежее, чем сбой. Реструктуризация 1С может раздуть журнал на десятки гигабайт: если в прошлый раз упали по 9002, сначала журнал транзакций и место, иначе копия снова умрёт на том же шаге.

Платформу 8.3 на SRV-1C не откатывайте вместе с базой, если клиенты уже обновлены и старая база на новой платформе поддерживается. Откат базы ≠ откат MSI платформы. Если cfu требовал новую платформу и вы откатились, клиенты с новой 8.3 могут отказаться открывать старую базу — держите дистрибутив предыдущей сборки.

Не оставляйте инфобазу в монопольном режиме после неудачного окна: регламент не стартует, пользователи не входят, и это выглядит как «1С сломалась», хотя это флаг кластера. Снимите монопольно после отката.

Как проверить, что проблема устранена

• Предприятие открывает Accounting на релизе до сбоя, контрольные документы на месте.
• Тестовое обновление на копии доходит до конца, пользователи на тесте провели сценарий.
• Есть новый backup после успешного теста, перед вторым окном на проде.

Если не помогло

• Restore не встаёт — ошибка restore, цепочка log.
• Файловая база после сбоя не открывается — повреждение 1CD, всё равно копия сначала.
• Ошибка воспроизводится на копии — это баг релиза/окружения: платформа, права, CFU. Не экспериментируйте на проде.
• Нужен перенос на другой SQL — перенос, не как способ «отменить обновление».

Профилактика

Чеклист в статье подготовки: копия, тест, монопольно, место, план отката, кто дежурит. Не обновляйте пятничным вечером без теста. Отключите регламент и обмен на окно. Журнал SQL в Full + место под рост log на реструктуризацию.

FAQ

Можно ли восстановить только «таблицы конфигурации» из backup?

Не как штатный метод. Целая база на момент «до», иначе расхождение данных и метаданных.

Пользователи уже ввели документы после неудачного обновления.

Аварийное состояние могло эти документы не зафиксировать. Сверьте с первичкой. Не склеивайте «почти обновлённую» и вчерашний backup таблично.

DT вместо SQL backup — достаточный откат?

DT — снимок на момент выгрузки, не замена full+log для клиент-серверной базы в Full recovery. Для отката обновления SQL backup предпочтительнее.

Кто должен жать кнопки: админ Windows или консультант 1С?

Админ отвечает за копию, диск, сеансы, SQL restore. Конфигурацию/cfu — консультант. Сбой «посредине» без копии — общий провал процесса, не «виноват SQL».

Нужно ли обновлять SQL Server вместе с 1С?

Нет в том же окне. Разведите риски: сначала СУБД по своему регламенту, 1С — отдельно после теста.