База 1С не открывается из-за повреждённого хранилища: проверка и восстановление по шагам

Сообщение Неверный формат хранилища данных в 1С 8.3 означает, что платформа прочитала из базы блок, который не смогла разобрать. Для файловой базы первое лечение — утилита chdbfl.exe из каталога bin платформы, затем Тестирование и исправление в конфигураторе. Для серверной базы сначала проверяют саму СУБД, и только потом — средствами 1С.

Частое заблуждение — искать в файловой базе Firebird. Его там нет: файловая база 1С 8.3 — это собственный формат, один файл 1Cv8.1CD. Поэтому советы «починить Firebird» к ней не относятся. Ошибка хранимых данных лечится по-разному в файловом и клиент-серверном варианте, и начинать нужно с выяснения, что именно сломалось.

Откуда берётся ошибка хранимых данных в 1С и как определить свой случай

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

Типичные источники:

• ⚡ аварийное отключение питания или «зависание» компьютера во время записи в базу;
• 🌐 файловая база лежит на сетевой папке, и связь оборвалась посреди транзакции;
• 🛡️ антивирус заблокировал или «вылечил» файл 1Cv8.1CD во время работы;
• 💽 сбойный диск: битые секторы, переполненный раздел, ошибка RAID;
• 🔢 база открыта платформой, номер версии которой ниже, чем у той, что создала или конвертировала базу;
• 📦 повреждённый кэш конфигурации на компьютере пользователя или на сервере 1С.

Рядом с основной ошибкой часто появляются и другие тексты: Файл базы данных поврежден, Ошибка формата потока, Нарушение целостности структуры конфигурации. Они указывают на тот же класс проблем и лечатся теми же средствами.

Прежде чем лечить: копия и монопольный режим

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

Сделайте копию повреждённой базы до любых исправлений, даже если она «и так сломана».

1. Попросите всех пользователей выйти из базы.
2. Для файловой базы скопируйте весь каталог базы целиком, а не только 1Cv8.1CD. Копию положите на другой диск.
3. Для серверной базы сделайте полный бэкап средствами СУБД: в MS SQL — BACKUP DATABASE, в PostgreSQL — pg_dump или копию каталога данных при остановленной службе.
4. Попробуйте выгрузить базу в .dt: Конфигуратор → Администрирование → Выгрузить информационную базу. Если выгрузка прошла — у вас уже есть чистая копия, и часто достаточно загрузить её в новую пустую базу.
5. Найдите последнюю рабочую резервную копию и запишите её дату. Это запасной путь, если ремонт не удастся.

Проверка файла 1Cv8.1CD утилитой chdbfl.exe

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

Где лежит утилита: в каталоге установленной платформы, например C:\Program Files\1cv8\8.3.24.1548\bin\chdbfl.exe. Номер версии в пути — ваш.

1. Убедитесь, что базу никто не открыл. Утилита требует монопольного доступа к файлу.
2. Запустите chdbfl.exe от имени администратора.
3. В поле с именем файла укажите путь к 1Cv8.1CD — лучше к копии.
4. Включите флажок Исправлять обнаруженные ошибки.
5. Нажмите Выполнить и дождитесь окончания. Для базы в 10–20 ГБ это может занять от десятков минут до нескольких часов.
6. Прочитайте журнал в окне утилиты: какие таблицы были повреждены и что удалено.

Берите chdbfl.exe той же версии, что и платформа, которой открываете базу. Утилита из другой версии может не понять формат файла.

Если chdbfl.exe завершилась без ошибок, а база всё равно не открывается, проблема не в физической структуре файла. Переходите к тестированию и исправлению или проверьте версию платформы.

Тестирование и исправление информационной базы в конфигураторе

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

Путь: Конфигуратор → Администрирование → Тестирование и исправление.

Какие пункты отмечать:

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

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

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /IBCheckAndRepair -ReIndex -LogAndRefsIntegrity -RecalcTotals -BadRefCreate -BadDataCreate /Out"D:\Logs\check.txt"

Для серверной базы вместо /F указывают /S"сервер\имябазы". Результат проверки пишется в файл из параметра /Out.

Неверный формат хранилища в серверной базе на MS SQL Server

В клиент-серверном варианте за хранение отвечает СУБД. Если повреждены страницы на стороне MS SQL, тестирование средствами 1С не поможет, пока не вылечена сама база SQL.

Порядок действий:

1. Проверьте базу в SQL Server Management Studio:

DBCC CHECKDB ('Buh') WITH NO_INFOMSGS, ALL_ERRORMSGS;

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

ALTER DATABASE Buh SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('Buh', REPAIR_REBUILD);
ALTER DATABASE Buh SET MULTI_USER;

4. Вариант REPAIR_ALLOW_DATA_LOSS применяйте только если REPAIR_REBUILD не помог и свежей копии нет. Он удаляет повреждённые страницы вместе с данными.
5. Очистите кэш сервера 1С и выполните Тестирование и исправление из конфигуратора.

Очистка кэша сервера 1С: остановите службу агента сервера 1С, удалите файлы snccntx* в каталоге кластера (обычно srvinfo\reg_1541\), запустите службу снова. Остановка службы прерывает работу всех баз на этом сервере, не только повреждённой.

Если в журнале SQL Server видны ошибки ввода-вывода (823, 824), проверьте диск. Пока диск сбоит, ремонт базы бесполезен: повреждения появятся снова.

Повреждение хранилища данных 1С на PostgreSQL

С PostgreSQL ошибку часто сопровождают тексты СУБД вроде invalid page in block или could not read block. Они прямо указывают на физическое повреждение таблицы или индекса.

Что делать по порядку:

1. Найдите в журнале PostgreSQL имя повреждённого объекта. Если это индекс, обычно хватает перестроения:

REINDEX TABLE имя_таблицы;

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

REINDEX DATABASE buh;

3. Проверьте, читаются ли все таблицы целиком. Простой способ — пробная выгрузка: pg_dump -Fc -f D:\check.backup buh. Если дамп остановился на конкретной таблице, повреждена именно она.
4. В PostgreSQL 14 и новее есть утилита pg_amcheck: она проверяет индексы и таблицы без выгрузки.
5. После лечения средствами СУБД выполните VACUUM ANALYZE и Тестирование и исправление в конфигураторе 1С.

Есть радикальный параметр zero_damaged_pages: он заставляет PostgreSQL обнулять битые страницы при чтении. Данные на этих страницах пропадают безвозвратно. Включайте его только на копии базы и только когда других вариантов нет.

Когда штатные средства не помогли: системные таблицы и файл 1Cv8.1CD

Внутри базы хранятся не только данные, но и служебные таблицы. Самые важные из них:

• Config — конфигурация базы данных;
• ConfigSave — основная конфигурация, изменения которой ещё не применены к базе;
• Params — служебные параметры базы;
• Files — служебные файлы платформы.

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

Для файловой базы есть сторонние утилиты, которые читают 1Cv8.1CD напрямую, например Tool_1CD. С их помощью можно посмотреть таблицы, вытащить из повреждённой базы конфигурацию и отдельные данные.

Ручная правка системных таблиц — последний шаг, и только на копии. Одна ошибка — и база перестанет открываться совсем. Часто разумнее взять последнюю рабочую копию и вручную дописать документы за недостающие дни.

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

• chdbfl.exe и тестирование завершаются аварийно;
• после исправления пропали остатки или проводки за закрытые периоды;
• повреждения появляются снова через несколько дней.

Как не допустить повреждения хранимых данных снова

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

Как правильно копировать файловую базу:

• 📁 копируйте 1Cv8.1CD только при закрытой базе — копия открытого файла может оказаться повреждённой;
• 📤 раз в неделю делайте выгрузку в .dt: она проверяет читаемость всех таблиц;
• 🗓️ храните несколько копий за разные дни, а не одну перезаписываемую.

Для серверных баз опирайтесь на средства СУБД: полный бэкап MS SQL плюс журналы транзакций, для PostgreSQL — pg_dump или pg_basebackup. Выгрузку .dt для больших серверных баз используйте как дополнение, а не как основную копию.

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