База данных 1С повреждена: что делать

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

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

Дальнейшие действия зависят от режима работы базы: файловый вариант (один файл 1Cv8.1CD) и клиент-серверный (MS SQL, PostgreSQL) требуют разных подходов. Ниже разобраны оба сценария, инструменты восстановления и границы, за которыми самостоятельные попытки становятся рискованными.

Первые действия: что сделать до любого восстановления

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

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

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

Диагностика: как понять характер повреждения

Текст ошибки и условия её появления помогают отличить логическое повреждение от аппаратного. Ошибка «Файл базы данных повреждён» с указанием пути к 1Cv8.1CD обычно означает нарушение внутренней структуры файла. Ошибки вида «Ошибка СУБД» в клиент-серверном варианте указывают на проблемы на стороне SQL-сервера, а не платформы 1С.

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

Восстановление файловой базы утилитой chdbfl.exe

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

Порядок работы: запустите chdbfl.exe, укажите путь к файлу базы (копии, а не оригиналу — если есть возможность), отметьте флаг «Исправлять обнаруженные ошибки» и запустите проверку. На больших базах процесс занимает заметное время. После завершения утилита покажет, были ли обнаружены и исправлены ошибки.

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

1. 1
   Скопируйте файл 1Cv8.1CD на другой диск
2. 2
   Запустите chdbfl.exe из каталога bin платформы
3. 3
   Укажите файл и включите исправление ошибок
4. 4
   Откройте базу в конфигураторе и запустите тестирование и исправление
5. 5
   Проверьте остатки, последние документы и ключевые отчёты

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

Второй штатный инструмент — пункт «Администрирование → Тестирование и исправление» в конфигураторе. Он работает и с файловыми, и с клиент-серверными базами и проверяет логическую целостность: ссылочную целостность, индексы, соответствие итогов.

Для повреждённой базы обычно выбирают проверки «Реиндексация таблиц», «Проверка ссылочной целостности» и «Проверка логической целостности», режим «Тестирование и исправление». Если база не открывается даже в конфигураторе, сначала прогоните chdbfl — часто после него конфигуратор уже запускается.

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

Восстановление из резервной копии

Если есть выгрузка .dt приемлемой свежести, это самый надёжный путь: создайте пустую базу и загрузите выгрузку через «Администрирование → Загрузить информационную базу». Проверка .dt проста — если файл загружается без ошибок в тестовую базу, он цел.

Для клиент-серверных баз восстановление делается средствами СУБД: в MS SQL — RESTORE из полной и, при наличии, разностной копии, в PostgreSQL — pg_restore из дампа. После восстановления проверьте базу штатными средствами СУБД (например, DBCC CHECKDB для MS SQL) и тестированием в конфигураторе.

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

Клиент-серверный режим: специфика восстановления

В клиент-серверном варианте файл 1Cv8.1CD отсутствует, поэтому chdbfl неприменим. Повреждения диагностируются средствами СУБД: для MS SQL Server — команда DBCC CHECKDB, которая показывает повреждённые страницы и объекты; для PostgreSQL — проверка через pg_amcheck или анализ логов сервера.

Исправление средствами СУБД (например, REPAIR_ALLOW_DATA_LOSS в MS SQL) — крайняя мера: она физически удаляет повреждённые страницы вместе с данными. Перед её применением сделайте полный бэкап текущего состояния базы, даже повреждённой. Во многих случаях разумнее восстановиться из последнего рабочего бэкапа, чем терять неизвестный объём данных.

Сравнение вариантов восстановления

Восстановление из бэкапа / .dt

Самый надёжный способ, но теряются данные после даты копии

chdbfl + тестирование

Подходит для файловых баз при умеренных повреждениях; не гарантирует сохранность отдельных записей

Исправление средствами СУБД

Для клиент-серверных баз; риск потери данных на повреждённых страницах

Специализированные сервисы восстановления

Крайний вариант при тяжёлых повреждениях и отсутствии копий; требует времени и средств

Типичные ошибки и профилактика

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

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

Третья — регламент: периодическое тестирование без исправления позволяет поймать логические ошибки раньше, чем они приведут к отказу базы. Для клиент-серверных систем полезен мониторинг логов СУБД и технологического журнала платформы.

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

База не открывается даже в конфигураторе — это безнадёжно?

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

chdbfl исправил ошибки, но часть документов пропала. Что делать?

Утилита удаляет записи, которые не может восстановить. Вернитесь к копии повреждённой базы (если она была сделана до исправления) и попробуйте выгрузить недостающие данные обработками или восстановить их из резервной копии. Без копии «до исправления» вернуть удалённые записи штатными средствами нельзя.

Можно ли работать с файловой базой по сети?

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

Как проверить, что восстановленная база в порядке?

Запустите тестирование и исправление со всеми проверками, сверьте ключевые показатели: остатки по счетам и складам, оборотно-сальдовую ведомость, наличие последних документов за период. Желательно сравнить итоги с данными из последней резервной копии или распечатанных отчётов.

Антивирус удалил файл базы — как его вернуть?

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

Как часто нужно делать резервные копии?

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