Слетела база 1С: порядок действий и способы восстановления

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

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

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

Сначала зафиксируйте состояние: копия перед любыми действиями

До запуска конфигуратора, утилит восстановления и любых проверок сделайте полную копию текущего состояния базы. Для файловой базы это каталог с файлом 1Cv8.1CD — скопируйте его целиком в отдельную папку на другом диске или сетевом ресурсе. Для клиент-серверной базы сделайте резервную копию средствами СУБД (например, через pgAdmin для PostgreSQL или SQL Server Management Studio), даже если база частично повреждена — иногда копия удаётся создать.

Эта копия — ваша точка невозврата. Если тестирование и исправление удалит «битые» объекты вместе с данными, а chdbfl обрежет повреждённые таблицы, вернуться к исходному состоянию без копии будет невозможно. Проверьте, что копия действительно создалась: сравните размер файла-источника и копии, убедитесь, что копирование завершилось без ошибок.

Параллельно убедитесь, что все пользователи вышли из базы и сеансы завершены. В файловом варианте проверьте отсутствие файла блокировок 1Cv8.1CL и процессов 1cv8.exe на компьютерах пользователей. Работа с базой, к которой кто-то подключён, приводит к новым повреждениям при попытке восстановления.

Диагностика: определяем тип и масштаб повреждения

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

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

Полезно сразу проверить системный журнал: наличие ошибок диска (chkdsk в Windows), события отключения питания, записи антивируса о перемещении файлов в карантин. Если антивирус отправил 1Cv8.1CD в карантин, восстановите его оттуда и добавьте каталоги 1С в исключения — иначе ситуация повторится.

Самый надёжный путь: восстановление из резервной копии

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

Для файловой базы восстановление сводится к замене каталога базы содержимым архивной копии или загрузке выгрузки .dt через конфигуратор (меню «Администрирование — Загрузить информационную базу»). Для клиент-серверной — восстановлением бэкапа средствами СУБД. После восстановления обязательно проверьте базу: откройте ключевые отчёты, сверьте остатки на контрольную дату, убедитесь, что пользователи могут войти.

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

Тестирование и исправление в конфигураторе

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

Ключевой момент — выбор режима обработки ошибок. Вариант «Удалять объект целиком» опасен: повреждённый документ будет удалён вместе с данными. Вариант «Не изменять» безопасен для первого прохода: вы получите список ошибок без изменений и сможете оценить масштаб. Разумная тактика — сначала прогон в режиме диагностики, анализ списка ошибок, затем осознанное исправление.

1. 1
   Сделайте копию файла базы и убедитесь, что она читается
2. 2
   Завершите все сеансы пользователей и фоновые задания
3. 3
   Откройте конфигуратор в монопольном режиме
4. 4
   Запустите «Администрирование — Тестирование и исправление» с режимом «Не изменять»
5. 5
   Изучите протокол: какие таблицы и объекты повреждены
6. 6
   Повторите процедуру с исправлением, выбирая безопасные режимы
7. 7
   Проверьте базу: вход, отчёты, остатки, ключевые документы

Отмечайте в настройках проверки только нужные пункты: «Реиндексация таблиц», «Проверка логической целостности», «Проверка ссылочной целостности». Полный набор проверок на большой базе может идти очень долго. Если повреждение затронуло только часть данных, иногда быстрее восстановить отдельные объекты из копии обработкой, чем чинить всю базу.

Утилита chdbfl для файловых баз

Когда файл 1Cv8.1CD повреждён настолько, что конфигуратор его не открывает, помогает утилита chdbfl.exe из каталога установки платформы (папка bin). Она проверяет физическую целостность файла базы и может исправлять повреждения таблиц. Работает только с файловым вариантом и только при закрытых сеансах.

Порядок простой: укажите путь к файлу 1Cv8.1CD, запустите проверку без исправлений, изучите отчёт. Если ошибки найдены, запустите проверку с включённой опцией исправления. Утилита может удалить безнадёжно повреждённые фрагменты — именно поэтому копия файла перед запуском обязательна.

C:\Program Files\1cv8\<версия>\bin\chdbfl.exe

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

Особенности клиент-серверных баз

Если база работает на PostgreSQL, MS SQL Server или другой СУБД, инструменты файлового варианта не подходят — chdbfl к серверной базе не применим. Диагностику начинайте с логов СУБД: там видно, есть ли ошибки страниц данных, проблемы с дисковой подсистемой или нехватка места для журнала транзакций — частая причина «слёта» серверных баз.

Для PostgreSQL используйте проверку целостности и при необходимости восстановление из WAL-архивов или бэкапа; для MS SQL — DBCC CHECKDB, который выявляет и в отдельных режимах исправляет повреждения. Режимы исправления с потерей данных (REPAIR_ALLOW_DATA_LOSS) — крайняя мера, после которой базу нужно тщательно проверять на пропавшие записи.

Если опыта администрирования СУБД нет, серверную базу лучше не чинить экспериментами. Ошибочные действия на уровне СУБД способны повредить не одну базу, а весь экземпляр сервера с несколькими базами компании.

Когда обращаться к специалистам и как не допустить повторения

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

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

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