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

Чего не делать никогда

  • Не перезаписывайте бэкапы. Первое побуждение — «сейчас восстановлюсь из вчерашнего» — и человек копирует битую базу поверх последней рабочей копии. Всё, что было до сбоя, сначала сохраните отдельно.
  • Не запускайте тестирование и исправление на единственном экземпляре. Штатное «Тестирование и исправление» умеет не только чинить, но и вычищать «повреждённые» данные безвозвратно. Только на копии.
  • Не жмите «удалить» на предложения платформы. Диалоги вида «объект повреждён, удалить?» — это необратимо.
  • Не переустанавливайте платформу «на всякий случай». Проблема почти никогда не в ней, а время уходит.

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

  1. Скопируйте базу как есть. Файловая — всю папку с 1Cv8.1CD; серверная — снимите бэкап СУБД. Это ваша страховка: теперь любые эксперименты обратимы.
  2. Прочитайте текст ошибки дословно. «Файл базы данных повреждён», «Ошибка формата потока», «Ошибка блокировки» — это три разные истории с разным способом восстановления. Сфотографируйте окно.
  3. Проверьте простое. Место на диске, доступность сервера, не держит ли базу зависший сеанс или антивирус. Треть «падений» — именно тут.
  4. Для файловой базы — штатная утилита проверки chdbfl.exe из каталога платформы: запускать на КОПИИ, сначала в режиме проверки без исправления.
  5. Для серверной — смотрите журнал СУБД и журнал регистрации 1С: они обычно называют виновника точнее любых догадок.

Что чинится и как

По моей практике исходы делятся на три группы:

  • Лёгкая: зависшие сеансы, блокировки, кэш платформы, место на диске — лечится за минуты, данные целы.
  • Средняя: повреждение файловой базы — chdbfl.exe на копии чинит большинство случаев; серверной — восстановление из бэкапа СУБД с накатом свежих документов руками или обработкой.
  • Тяжёлая: бэкапов нет, база повреждена глубоко. Даже здесь часть данных обычно спасается — выгрузкой уцелевших объектов на уровне СУБД, — но это уже ювелирная работа, и каждый лишний запуск «исправления» уменьшает шансы.

Когда звать специалиста

Если после пунктов 1–3 база не ожила — дальше каждый шаг наугад снижает вероятность полного восстановления. Специалисту для диагностики нужна копия базы (.dt или архив папки) и текст ошибки — по ним обычно за час понятно, к какой группе относится ваш случай и что реально спасти.

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