Повреждённая база 1С: от диагностики диска до восстановления данных

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

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

Первый осмотр: где сломалось и что говорят журналы

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

Типичные тексты, которые сопровождают повреждение файловой базы:

• 🔴 Файл базы данных поврежден — при запуске или при открытии конкретного списка;
• 🔴 Ошибка формата потока — платформа не смогла прочитать сохранённые данные или кэш;
• 🔴 Нарушение целостности структуры конфигурации — повреждены таблицы с конфигурацией;
• 🔴 Ошибка СУБД с упоминанием файла базы — общий текст файлового движка.

Сначала запишите точный текст и момент, когда он появляется. Затем ответьте себе на три вопроса:

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

Журнал регистрации

Журнал файловой базы лежит в подкаталоге 1Cv8Log рядом с 1Cv8.1CD. В зависимости от формата это либо файл 1Cv8.lgd, либо набор файлов .lgf и .lgp. Если база открывается, журнал можно посмотреть в конфигураторе: Администрирование → Журнал регистрации.

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

Проверка диска

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

• 💾 посмотрите SMART диска любой диагностической программой: переназначенные и нестабильные сектора — сигнал менять диск;
• 💾 проверьте свободное место: если диск был заполнен до нуля, запись в базу могла оборваться на середине;
• 💾 запустите проверку файловой системы командой chkdsk D: /f (букву диска замените на свою).

Утилита chdbfl.exe: ремонт физической структуры файла

chdbfl.exe — штатная утилита проверки физической целостности файловой базы. Она входит в поставку платформы и лежит в каталоге вида C:\Program Files\1cv8\8.3.xx.xxxx\bin\. Отдельно её скачивать не нужно.

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

Порядок работы:

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

Результат утилита пишет в окно. Сохраните этот текст: в нём видно, какие таблицы пострадали. Если в списке таблицы конфигурации (их имена начинаются с CONFIG), стоит заранее подготовить файл конфигурации .cf той же версии — может понадобиться.

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

После chdbfl.exe файл обычно открывается, но логика данных может остаться битой: ссылки на удалённые объекты, неверные итоги регистров. Это лечит режим Администрирование → Тестирование и исправление в конфигураторе.

Этот режим требует монопольного доступа к базе. Отключите пользователей заранее.

Какие проверки включать:

Сначала выберите режим «Только тестирование». Посмотрите, сколько проблем нашлось и каких. Потом запускайте «Тестирование и исправление».

Для битых ссылок есть три варианта: создавать объекты, очищать ссылки, не изменять. Выбор влияет на данные:

• 🧩 Создавать объекты — платформа создаст пустые элементы-заглушки. Документы останутся целыми, а заглушки потом можно найти и заполнить. Самый щадящий вариант.
• 🧩 Очищать ссылки — поле в документе станет пустым. Документ может перестать проводиться.
• 🧩 Не изменять — только отчёт, без правки.

Для частичной потери объектов аналогично: создавать, удалять или не изменять. Удаление необратимо, поэтому начинайте с создания.

Тот же режим можно запустить из командной строки, например ночью по расписанию:

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

Ключ -TestOnly включает режим только проверки. Отчёт пишется в файл из параметра /Out.

Выгрузка в DT и загрузка в чистую базу

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

Пошагово:

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

Если выгрузка обрывается с ошибкой на какой-то таблице — это хорошая подсказка. Сначала повторите chdbfl.exe и «Тестирование и исправление», потом выгружайте снова.

Если не помогло

Бывает, что конфигурация читается, а данные — нет. Тогда план такой:

• 📦 сохраните конфигурацию в файл: Конфигурация → Сохранить конфигурацию в файл;
• 📦 создайте новую базу из этого .cf;
• 📦 перенесите читаемые данные универсальной обработкой выгрузки и загрузки данных в XML — по справочникам и документам, частями;
• 📦 недостающий период досоздайте из резервной копии или введите заново.

Это долгая работа, но она спасает данные, когда файл разрушен частично.

Когда база на SQL-сервере: что меняется

В клиент-серверном варианте файла 1Cv8.1CD нет. Данные хранит СУБД — MS SQL Server или PostgreSQL. Поэтому chdbfl.exe здесь не применяется, а похожие ошибки означают сбой на стороне СУБД или кэша кластера 1С.

Что проверить в первую очередь:

1. Журнал СУБД. В MS SQL это журнал ошибок сервера, в PostgreSQL — лог в каталоге данных. Ищите ошибки чтения страниц и ввода-вывода.
2. Целостность базы в СУБД. Для MS SQL запустите проверку:

DBCC CHECKDB ('ИмяБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;

3. Тестирование и исправление. Режим из конфигуратора доступен и для серверной базы, но работает на уровне 1С: реиндексация, логическая и ссылочная целостность, итоги.
4. Сервер 1С и кэш. Если ошибка «формата потока» плавает и пропадает после перезапуска, виноват может быть сеансовый кэш кластера, а не данные.

Если DBCC CHECKDB нашёл ошибки, не спешите с параметрами восстановления, допускающими потерю данных. Сначала сделайте резервную копию базы средствами СУБД и восстановите её на тестовый сервер. Ремонт с потерей данных — последний шаг, и решение о нём принимает администратор СУБД.

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

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

Порядок для файловой базы:

1. Переименуйте каталог повреждённой базы, например в Buh_broken.
2. Создайте новый каталог с прежним именем.
3. Если копия в виде файла 1Cv8.1CD — скопируйте его в новый каталог.
4. Если копия в виде .dt — создайте пустую базу и загрузите файл через конфигуратор.
5. Откройте базу, найдите дату копии и составьте список того, что вводили после неё.

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

Где ещё искать копию, если «бэкапов нет»:

• 🗂 встроенное резервное копирование в типовых конфигурациях на БСП: Администрирование → Обслуживание → Резервное копирование и восстановление — посмотрите, куда оно было настроено;
• 🗂 автоматические копии перед обновлением конфигурации, если их делал тот, кто обновлял;
• 🗂 теневые копии Windows и предыдущие версии файлов на томе с базой;
• 🗂 облачные синхронизации и сетевые хранилища, куда попадала папка базы.

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

Ремонт без устранения причины — отсрочка. Вот что реально снижает риск:

• ⚡ Бесперебойник на сервере или компьютере с базой. Обрыв питания во время записи — классика.
• 🌐 Не работайте с файловой базой по сети через общую папку на нескольких пользователях без необходимости. При нестабильной сети запись обрывается. Для 5 и более активных пользователей лучше публикация на веб-сервере или клиент-серверный вариант.
• 🛡 Исключение для антивируса: добавьте каталог базы в исключения сканирования. Антивирус, блокирующий 1Cv8.1CD в момент записи, — частая причина.
• 🧹 Не снимайте процесс 1cv8 через диспетчер задач, когда идёт проведение или обмен. Если 1С зависла — подождите, затем завершайте.
• 💾 Свободное место: держите на диске с базой запас не меньше размера самой базы — он нужен и для работы, и для выгрузки в .dt.
• 📊 Мониторинг диска: проверка SMART раз в месяц и замена диска при первых переназначенных секторах.

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

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "D:\Bases\Buh" /N "Администратор" /P "пароль" /DumpIB "E:\Backup\buh_%date:~-4%%date:~3,2%%date:~0,2%.dt"

Выгрузка требует отсутствия пользователей в базе, поэтому ставьте задание на ночь. Раз в квартал проверяйте копию: разверните .dt в тестовую базу и откройте отчёт. Непроверенная копия — не копия.

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