Как лечить базу 1С: диагностика, исправление ошибок и восстановление данных

«Лечение» базы 1С — это комплекс действий по устранению ошибок в файле базы или в данных: от штатного тестирования и исправления в конфигураторе до низкоуровневой утилиты chdbfl.exe и полной выгрузки-загрузки через dt-файл. Поводом обычно служат сообщения вида «Ошибка формата потока», «Файл базы данных поврежден», зависания при открытии документов или внезапное пропадание записей.

Причины повреждений почти всегда технические: аварийное отключение питания во время записи, обрыв сети при файловом доступе к базе, сбой диска, работа антивируса с файлами 1Cv8.1CD, нехватка места на диске. Реже базу «ломают» нештатные обработки и прямые правки данных.

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

Признаки повреждения базы и первичная диагностика

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

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

Первичная диагностика занимает 10–15 минут и позволяет понять масштаб беды: открывается ли база в конфигураторе, открывается ли она с другого компьютера, воспроизводится ли ошибка после очистки кэша, есть ли свободное место на диске с базой.

Обязательная подготовка: резервная копия

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

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

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

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

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

В нижней части окна выбирается режим: «Тестирование» (только диагностика, безопасно) или «Тестирование и исправление». Разумная тактика — сначала прогнать чистое тестирование, изучить список ошибок и только потом включать исправление, понимая, что именно будет изменено.

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

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

Утилита chdbfl.exe: когда конфигуратор бессилен

Если база не открывается даже в конфигураторе, на помощь приходит chdbfl.exe — низкоуровневая утилита проверки физической целостности файловой базы. Она лежит в каталоге установки платформы, в папке bin конкретной версии (например, bin\chdbfl.exe).

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

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

Выгрузка и загрузка через dt как способ «пересборки» базы

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

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

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

Сравнение методов лечения

Тестирование и исправление

Штатный и безопасный старт. Требует монопольного доступа; не помогает, если база не открывается

chdbfl.exe

Единственный вариант, когда база не открывается совсем. Может вырезать повреждённые записи безвозвратно

Выгрузка/загрузка dt

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

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

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

Серверные базы: отличия и особые риски

В клиент-серверном варианте файл 1Cv8.1CD отсутствует — данные живут в СУБД, и лечить их нужно её инструментами. Для MS SQL это проверка целостности DBCC CHECKDB и восстановление из резервной копии; для PostgreSQL — проверки целостности и pg_basebackup/архивы WAL.

Тестирование и исправление из конфигуратора для серверной базы тоже доступно и работает, но монопольный режим на сервере означает остановку работы всех пользователей — это делается в нерабочее время по регламенту. Выгрузка dt для крупных серверных баз практически не применяется из-за объёмов; роль снимков выполняют бэкапы СУБД.

Критическое правило: никогда не правьте данные серверной базы напрямую SQL-запросами UPDATE/DELETE без глубокого понимания структуры. Прямые изменения обходят логику платформы, ломают итоги, служебные таблицы и версионирование — и создают проблемы, которые потом не диагностируются штатными средствами.

Маршрут решения

Как выбрать действие

База открывается, но есть ошибки в данных или итогахТестирование и исправление в конфигураторе с нужными проверками

Файловая база не открывается вообщеchdbfl.exe с флагом исправления, затем тестирование в конфигураторе

База работает, но тормозит и периодически сбоитВыгрузка в dt и загрузка в новую чистую базу

Серверная база повреждена на уровне СУБДПроверка средствами СУБД и восстановление из последнего бэкапа

Повреждение серьёзное, а бэкапа нетСкопируйте файл базы как есть и привлеките специалистов по восстановлению данных

Проверка результата и профилактика повреждений

После любого лечения нужно убедиться, что база не просто открывается, а работает корректно. Контрольный минимум: открываются объекты, на которых возникали ошибки; ключевые отчёты (ОСВ, взаиморасчёты, остатки склада) сходятся с данными до сбоя или с копией; документы проводятся без ошибок; фоновые задания выполняются.

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

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

Контрольные точки

Как проверить результат

Открытие базы и проблемных объектов

Норма

База и объекты открываются без сообщений об ошибках

Тревожный признак

Ошибки формата потока или падения сохраняются

Ключевые отчёты

Норма

Обороты и сальдо совпадают с данными копии или прошлого периода

Тревожный признак

Появились пустоты, дубли или расхождения итогов

Проведение документов

Норма

Новые и старые документы проводятся штатно

Тревожный признак

Ошибки блокировок, ссылок или записи регистров

Повторное тестирование

Норма

Проверка не находит ошибок

Тревожный признак

Те же ошибки возвращаются — повреждение глубже, нужен другой метод

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

Можно ли лечить базу, пока пользователи работают?

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

Что делать, если chdbfl не нашёл ошибок, а база всё равно не открывается?

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

Выгрузка в dt обрывается с ошибкой — база безнадёжна?

Нет. Ошибка выгрузки указывает на конкретную повреждённую таблицу. Прогоните chdbfl и тестирование с исправлением, затем повторите выгрузку. Если конкретная таблица не восстанавливается, данные из неё иногда удаётся частично спасти переносом остатков из копии или из отчётов.

Как часто нужно делать тестирование и исправление в профилактических целях?

Регулярное плановое ТиИ не обязательно, если база работает стабильно. Разумный минимум — после каждого аварийного завершения (отключение питания, сбой сервера) и перед масштабными операциями вроде обновления конфигурации или свёртки базы.

Поможет ли переустановка платформы 1С при ошибках базы?

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

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

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