Восстановление повреждённой информационной базы 1С 8.3: от утилиты chdbfl до средств СУБД
Содержание
Если база данных 1С повреждена, первым делом скопируйте её каталог целиком, а потом идите от мягкого к жёсткому. Для файловой базы это утилита chdbfl.exe из каталога платформы. Дальше — Администрирование → Тестирование и исправление в Конфигураторе. Если не помогло — выгрузка в .dt и загрузка в новую базу. В клиент-серверном варианте сначала проверяют саму СУБД, затем запускают тестирование средствами 1С. Последний вариант — восстановление из резервной копии.
Порядок важен. Каждая следующая операция меняет данные сильнее предыдущей, а часть исправлений необратима. Поэтому без копии исходного состояния ни один из шагов ниже не запускайте.
Как понять, что база 1С повреждена
Повреждение редко выглядит как одна понятная ошибка. Чаще база открывается, но падает на конкретном документе, отчёте или при записи. Типичные сообщения:
- 🔴
Файл базы данных поврежден— классика файлового варианта, платформа не может прочитать страницу файла1Cv8.1CD; - 🔴
Ошибка формата потока— данные в таблице или в кэше не читаются в ожидаемом формате; - 🔴
Нарушена целостность структуры конфигурации— повреждены служебные таблицы конфигурации; - 🔴
Неустранимая ошибкапри открытии конкретного документа или справочника; - 🔴
Ошибка СУБДс текстом от Microsoft SQL Server или PostgreSQL — в клиент-серверном варианте.
Косвенные признаки тоже стоит знать:
- 🟡 в списке документов появились строки
<Объект не найден>с длинным идентификатором; - 🟡 остатки в отчётах не сходятся с оборотно-сальдовой ведомостью, хотя никто ничего не правил;
- 🟡 программа зависает или вылетает всегда на одном и том же действии;
- 🟡 размер файла
1Cv8.1CDрезко изменился без видимой причины.
Ошибка формата потока не всегда означает повреждение самой базы. Часто ломается локальный кэш на компьютере пользователя. Сначала запустите базу с параметром /ClearCache или удалите базу из списка и добавьте снова. Если ошибка ушла — сама база цела.
Почему информационная база 1С портится
Знание причины подсказывает, где искать проблему и как не допустить повтора.
| Причина | Как проявляется | Где обычно бывает |
|---|---|---|
| Отключение питания во время записи | Ошибка сразу после включения | Файловые базы без ИБП |
| Работа файловой базы по сети через нестабильный канал | Ошибки у части пользователей, порча после обрыва Wi-Fi или VPN | Офисы, где база лежит в общей папке |
| Сбой диска, нехватка места | Ошибки чтения, «рваные» страницы | Старые HDD, переполненный системный диск |
Антивирус проверяет 1Cv8.1CD на лету | Блокировки, медленная работа, порча при записи | Любые компьютеры без исключений в антивирусе |
| Прерванное обновление конфигурации | Ошибки структуры, база не запускается | Обновление «вечером на бегу» |
| Сбой или ошибка на стороне СУБД | Ошибка СУБД, сообщения о повреждённых страницах | Клиент-серверный вариант |
Отдельно — синхронизация через облачные папки вроде Яндекс Диска. Если файл базы лежит в такой папке, клиент синхронизации может копировать его в момент записи. Хранить рабочую базу в синхронизируемом каталоге нельзя.
Подготовка к восстановлению: копия и монопольный доступ
Все операции ремонта требуют, чтобы в базе не было других пользователей. Тестирование и исправление, загрузка .dt и chdbfl.exe работают только в монопольном режиме.
Порядок подготовки:
- Предупредите пользователей и выберите время, когда в базе никто не работает . Если кто-то останется в программе, его сеанс придётся завершить, и несохранённые данные пропадут.
- Закройте все сеансы. В файловом варианте проверьте, что ни у кого не открыта 1С с этой базой. В клиент-серверном завершите сеансы через консоль администрирования серверов 1С.
- Сделайте копию в исходном, повреждённом виде. Для файловой базы скопируйте весь каталог, а не только
1Cv8.1CD. Для клиент-серверной — сделайте резервную копию средствами СУБД. - Проверьте свободное место на диске. Для ремонта и выгрузки нужно не меньше двух-трёх объёмов базы.
Не пытайтесь чинить единственный экземпляр базы. Утилиты исправления удаляют нечитаемые данные. Если результат окажется хуже исходного, вернуться можно только к копии.
Выгрузка в .dt из повреждённой базы часто падает с той же ошибкой. Поэтому копию первого шага делайте копированием файлов или средствами СУБД, а не через выгрузку.
Способы исправить повреждённую базу 1С: пять шагов
Шаги идут от безопасного к радикальному. После каждого запускайте базу и проверяйте проблемное место. Помогло — дальше не идите.
Шаг 1. Утилита chdbfl.exe для файловой базы
chdbfl.exe проверяет физическую структуру файла 1Cv8.1CD. Она не запускает конфигурацию, поэтому работает даже тогда, когда база вообще не открывается.
- Откройте каталог установленной платформы, например
C:\Program Files\1cv8\8.3.24.1586\bin\. Номер версии подставьте свой. - Запустите
chdbfl.exeот имени администратора. - Укажите путь к файлу
1Cv8.1CD. - Сначала запустите проверку без флажка исправления. Посмотрите, сколько ошибок найдено.
- Затем установите флажок исправления обнаруженных ошибок и запустите снова.
Если утилита пишет, что ошибок нет, а база всё равно не работает — проблема на логическом уровне. Переходите к шагу 2.
Шаг 2. Тестирование и исправление в Конфигураторе
Основной инструмент ремонта. Откройте базу в режиме Конфигуратора и выберите Администрирование → Тестирование и исправление. Появится окно с набором проверок.
| Флажок | Что делает | Когда включать |
|---|---|---|
| Реиндексация таблиц информационной базы | Перестраивает индексы | Почти всегда, безопасно |
| Проверка логической целостности | Ищет нарушения во внутренней структуре таблиц | Всегда |
| Проверка ссылочной целостности | Ищет ссылки на несуществующие объекты | При <Объект не найден> |
| Пересчёт итогов | Пересчитывает итоги регистров | При расхождении остатков |
| Сжатие таблиц | Убирает пустое место | Только для файловой базы |
| Реструктуризация таблиц | Пересоздаёт таблицы | Крайний случай, долго |
Ниже выбирается режим: только тестирование или тестирование с исправлением. Отдельно настраивается поведение при битых ссылках. Можно создавать объекты-заглушки, очищать ссылки или ничего не делать.
💡 Для первого прохода выбирайте создание объектов. Тогда на месте потерянного элемента справочника появится заглушка, и вы увидите, где именно была дыра. Если ссылку очистить, документ останется без контрагента или номенклатуры, и найти такие документы потом сложнее.
Если Конфигуратор не открывается, тот же набор проверок запускается из командной строки, в пакетном режиме:
"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" DESIGNER /F"D:\Base\Buh" /N"Администратор" /P"пароль" /IBCheckAndRepair -ReIndex -LogIntegrity -RecalcTotals -BadRefCreate /Out"D:\Logs\check.txt"
Ключ -TestOnly запускает проверку без исправления. Для клиент-серверной базы вместо /F указывают /S"сервер\имябазы". Результат пишется в файл из параметра /Out.
Шаг 3. Выгрузка в .dt и загрузка в новую базу
Выгрузка-загрузка пересобирает базу с нуля. Платформа читает все данные и записывает их в чистую структуру. Это помогает, когда тестирование прошло, а ошибки остались.
- В Конфигураторе:
Администрирование → Выгрузить информационную базу, сохраните файл.dt. - Создайте новую пустую информационную базу.
- Откройте её в Конфигураторе:
Администрирование → Загрузить информационную базу, выберите файл. - Запустите новую базу в режиме 1С:Предприятие и проверьте проблемные документы.
Если выгрузка обрывается на ошибке, значит, повреждённые данные читаются с трудом. Вернитесь к шагу 2 и запустите исправление с реструктуризацией таблиц, затем повторите выгрузку.
Загрузка .dt полностью заменяет данные в базе-приёмнике. Никогда не загружайте файл в рабочую базу, если не уверены, что это нужная выгрузка.
Шаг 4. Проверка средствами СУБД в клиент-серверном варианте
В клиент-серверном варианте данные хранит СУБД. Если повреждены страницы на стороне Microsoft SQL Server или PostgreSQL, тестирование из Конфигуратора может не помочь. Работу ведёт администратор СУБД.
Для Microsoft SQL Server сначала запускают проверку без исправления:
DBCC CHECKDB ('buh_base') WITH NO_INFOMSGS;
Если ошибки найдены, решение принимают по отчёту. Режим REPAIR_ALLOW_DATA_LOSS требует однопользовательского режима базы и может удалить повреждённые страницы вместе с данными. Применяют его только после копии, а потом обязательно запускают тестирование и исправление в 1С.
Для PostgreSQL типовой порядок такой:
REINDEX DATABASE buh_base;
VACUUM ANALYZE;
Хорошая проверка читаемости — пробная выгрузка базы через pg_dump в отдельный файл. Если дамп обрывается на конкретной таблице, повреждена именно она.
Перед этими операциями завершите сеансы 1С и заблокируйте начало новых сеансов в консоли кластера. REINDEX блокирует таблицы, пользователи получат ошибки и могут потерять несохранённые данные. Запускайте в нерабочее время.
Шаг 5. Восстановление из резервной копии
Если первые четыре шага не помогли или удалили слишком много, база восстанавливается из последней рабочей копии. Данные, введённые после неё, придётся внести заново.
Что можно спасти из повреждённой базы перед заменой:
- 📄 документы за последние дни — через обмен или выгрузку в универсальном формате, если базу ещё удаётся открыть;
- 📄 отдельные справочники — если повреждены не они;
- 📄 журнал регистрации — он покажет, какие документы вводили после даты копии.
Журнал регистрации здесь особенно полезен. Отбор по дате и событию «Данные. Добавление» даёт готовый список того, что нужно ввести заново.
Если база 1С не восстанавливается ни одним способом
Бывает, что все пять шагов пройдены, а база не открывается или копии нет. Варианты остаются.
- 🔧 Перенос данных в чистую базу. Создайте новую базу из типовой поставки той же конфигурации. Из повреждённой выгрузите то, что читается, через обработку универсального обмена данными. Сначала справочники, потом остатки на начало периода, потом документы.
- 🔧 Восстановление конфигурации отдельно от данных. Если повреждена только конфигурация, в Конфигураторе сохраните её в файл
.cf, если это возможно, или возьмите типовой.cfтой же версии. Затем загрузите в базу и обновите конфигурацию базы данных. - 🔧 Проверка диска. Если ошибки появляются снова после каждого ремонта, причина в оборудовании. Проверьте диск штатными средствами системы и перенесите базу на другой носитель.
- 🔧 Специалисты по восстановлению данных. Когда диск физически повреждён, домашние эксперименты только ухудшают ситуацию. Снимите с диска образ и отдайте его в лабораторию.
Рукописная правка файла 1Cv8.1CD сторонними редакторами — путь для специалистов. Без опыта такая правка превращает частично читаемую базу в нечитаемую.
Как не допустить повреждения базы 1С
Профилактика дешевле любого ремонта. Набор мер небольшой.
- 💾 Регулярные копии. Ежедневно, с хранением нескольких версий, на другом диске или сервере. Раз в месяц проверяйте, что копия разворачивается.
- 🔌 ИБП. Для сервера с файловой базой — обязательно. Корректное завершение при пропадании питания убирает самую частую причину порчи.
- 🌐 Не держать файловую базу на нестабильной сети. Если пользователей больше 3–5 или они работают через VPN, переходите на публикацию через веб-сервер, удалённый рабочий стол или клиент-серверный вариант.
- 🛡️ Исключения в антивирусе. Добавьте каталог базы и процессы платформы в исключения проверки на лету.
- 🧹 Плановое тестирование. Раз в квартал запускайте тестирование и исправление в режиме только проверки. Это занимает минуты для небольших баз и показывает проблемы до того, как они проявятся у бухгалтера.
- 🔄 Обновления по правилам. Копия перед обновлением, никаких обновлений во время работы пользователей.
Ошибки при восстановлении базы, из-за которых теряют данные
Большинство безвозвратных потерь связано не с самим повреждением, а с действиями после него.
- Ремонт без копии исходного состояния. Исправление удалило записи, результат хуже, вернуться не к чему.
- Сразу «полный набор» флажков. Реструктуризация и очистка битых ссылок на первом проходе стирают следы. Начинайте с проверки без исправления, чтобы увидеть масштаб.
- Очистка битых ссылок вместо создания объектов. Документы остаются с пустыми реквизитами, и их уже не отличить от правильно заполненных.
- Загрузка старой копии поверх рабочей базы. Вместо одной испорченной базы получается одна старая. Восстанавливайте копию в отдельную новую базу и сравнивайте.
- Ремонт при активных сеансах. Пользователь, которого «выкинуло» в процессе, повторяет операции, и данные расходятся.
- Игнорирование причины. Базу починили, а диск остался тот же. Через неделю всё повторяется.