Администрирование · 11 мин
Как починить базу 1С после сбоя: пошаговое руководство
Пошаговая инструкция по восстановлению базы 1С: тестирование и исправление, chdbfl.exe, выгрузка в dt, работа с кэшем и SQL. Риски, ошибки и FAQ.
Сбой базы 1С проявляется по-разному: программа не запускается, вылетает с ошибкой «Файл базы данных поврежден», зависает при открытии документов или показывает «Ошибка формата потока». Причины чаще всего одни и те же — внезапное отключение питания, разрыв сети при работе по сети, переполнение диска, сбой жёсткого диска или некорректное завершение сеанса. Хорошая новость: большинство повреждений файловой базы устраняется штатными средствами без потери данных.
Главное правило перед любыми действиями — сделать копию. Даже если база не открывается, скопируйте файл 1Cv8.1CD (для файловой базы) или сделайте выгрузку средствами СУБД (для клиент-серверной). Любой инструмент восстановления, включая штатное тестирование и исправление, может ухудшить состояние базы, и без резервной копии откатиться будет некуда.
Как понять, что база повреждена, и оценить масштаб проблемы
Не каждая ошибка означает физическое повреждение данных. «Ошибка формата потока» нередко вызвана испорченным кэшем метаданных и лечится простой очисткой кэша, а не ремонтом базы. Ошибки вида «не обнаружено ключевое слово» или отсутствие таблицы чаще связаны с несоответствием версий платформы и конфигурации.
Тревожные признаки именно повреждения: сообщение «Файл базы данных поврежден» с указанием пути к 1Cv8.1CD, ошибки чтения страниц данных, невозможность открыть базу даже в конфигураторе, пропажа части документов или записей в справочниках. Если ошибка возникает только у одного пользователя, а у остальных база работает — почти наверняка проблема в локальном кэше, а не в данных.
Очистите кэш метаданных на его компьютере
Запустите chdbfl.exe, затем тестирование и исправление
Тестирование и исправление с проверкой ссылочной целостности
Сначала chdbfl, затем повторная выгрузка
Подготовка: резервная копия перед любыми действиями
Завершите все сеансы пользователей и закройте 1С. Для файловой базы найдите каталог базы (путь виден в списке баз при запуске, внизу окна выбора) и скопируйте файл 1Cv8.1CD целиком в отдельную папку. Это займёт время при большом размере, но именно эта копия станет страховкой, если ремонт пойдёт не по плану.
Для клиент-серверной базы (MS SQL, PostgreSQL) сделайте полную резервную копию средствами СУБД — например, стандартный backup в SQL Server Management Studio. Не копируйте файлы mdf/ldf напрямую при работающем сервере: получите несогласованную копию.
Шаг 1. Очистка кэша — самое простое лечение
Кэш метаданных хранится в профиле пользователя и часто портится при обрывах соединения. Его повреждение имитирует поломку базы, хотя сами данные целы. Очистка кэша безопасна: 1С пересоздаст его при следующем запуске.
Самый надёжный способ — удалить базу из списка в окне запуска (кнопка «Удалить», данные при этом не трогаются) и добавить её заново, указав тот же путь. Точный путь к кэшу — папки с длинными шестнадцатеричными именами в каталогах %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8 — их тоже можно удалить вручную при закрытой 1С.
Шаг 2. Восстановление утилитой chdbfl.exe
Chdbfl.exe — штатная утилита проверки физической целостности файловых баз, поставляемая вместе с платформой. Она лежит в каталоге bin установленной версии платформы, например C:\Program Files\1cv8\<номер версии>\bin\chdbfl.exe. Утилита работает на низком уровне и часто справляется там, где конфигуратор базу даже не открывает.
- 1Закройте все сеансы 1С и убедитесь, что копия базы сделана
- 2Запустите chdbfl.exe из каталога bin платформы
- 3В поле «Имя файла БД» укажите путь к 1Cv8.1CD
- 4Установите флажок «Исправлять обнаруженные ошибки»
- 5Нажмите «Выполнить» и дождитесь окончания проверки
- 6Изучите отчёт: какие таблицы повреждены и что исправлено
- 7Откройте базу в конфигураторе и проверьте работоспособность
Проверка большой базы может занять десятки минут — не прерывайте процесс. Если утилита сообщает об исправленных ошибках, это ещё не означает полного восстановления логики данных: физически файл читается, но ссылки между объектами могут быть нарушены. Поэтому следующий шаг обязателен.
Шаг 3. Тестирование и исправление в конфигураторе
Откройте базу в конфигураторе (в монопольном режиме — пользователи не должны работать) и выберите меню «Администрирование — Тестирование и исправление». Для первого прохода рекомендуется включить проверку логической целостности и ссылочной целостности, а вариант обработки ошибок выбрать осознанно.
Обратите особое внимание на настройку «При наличии ссылок на несуществующие объекты». Вариант «Создавать объекты» безопаснее: вместо удаления записей с битыми ссылками будут созданы объекты-заглушки, которые потом можно найти и обработать вручную. Вариант «Очищать ссылки» или «Удалять объект» приводит к реальной потере данных — применяйте его, только понимая последствия.
После завершения изучите протокол: там перечислены найденные и исправленные ошибки. Запустите базу в режиме предприятия, откройте ключевые документы и отчёты за последний период, сверьте остатки по основным регистрам с последними известными значениями.
Шаг 4. Если база не восстанавливается: выгрузка и пересоздание
Когда chdbfl и тестирование не помогли, а конфигуратор всё ещё открывает базу хотя бы частично, попробуйте выгрузку в файл .dt («Администрирование — Выгрузить информационную базу»). Затем создайте новую пустую базу из того же шаблона конфигурации и загрузите в неё dt. Выгрузка-загрузка пересоздаёт структуру таблиц заново и часто «вытягивает» данные из повреждённого файла.
Если выгрузка обрывается с ошибкой на конкретной таблице, это указывает на место повреждения. Иногда помогает выгрузка через XML средствами встроенной обработки «Выгрузка и загрузка данных XML» по частям — справочники отдельно, документы отдельно. Крайний вариант — восстановление из последней архивной копии с последующим ручным вводом данных за потерянный период.
Сравнение способов восстановления
Помогает при ошибках формата потока; данные не затрагиваются, риска нет
Лечит физические повреждения файла; не проверяет логику и ссылки
Восстанавливает логическую и ссылочную целостность; при неверных настройках удаляет данные
Пересоздаёт структуру базы; требует, чтобы конфигуратор открывал базу
Гарантированный результат, но теряются данные после даты копии
Особенности клиент-серверных баз
Если база работает на MS SQL Server или PostgreSQL, файл 1Cv8.1CD отсутствует, и chdbfl неприменима. Повреждения на уровне СУБД диагностируются её средствами: для MS SQL — команда DBCC CHECKDB, которая покажет повреждённые страницы и индексы. Восстановление выполняется либо через DBCC с параметрами ремонта (с риском потери данных на повреждённых страницах), либо через восстановление из backup.
Тестирование и исправление в конфигураторе при этом остаётся актуальным: оно проверяет логику данных независимо от типа СУБД. Порядок тот же — сначала копия средствами СУБД, затем проверка СУБД, затем тестирование и исправление в монопольном режиме.
Как выбрать действие
Проверка результата и профилактика повторных сбоев
После восстановления недостаточно того, что база просто открылась. Проверьте ключевые участки: остатки по складу и расчётам с контрагентами, проведение новых документов, формирование регламентированной отчётности, работу обменов данными, если они настроены. Найдите объекты-заглушки, созданные при исправлении ссылок, и замените их корректными данными.
Чтобы ситуация не повторилась, настройте регулярное резервное копирование (ежедневное для активно используемой базы), подключите источник бесперебойного питания серверу, не размещайте файловую базу на сетевом диске с нестабильным соединением и следите за свободным местом на диске. Регулярная выгрузка в .dt — дополнительная страховка: из неё база восстанавливается даже при полном разрушении исходного файла.
Как проверить результат
Открывается без ошибок у всех пользователей
Ошибка сохраняется или появляется у части пользователей
Совпадают с последними известными значениями
Расхождения, обнулённые или отрицательные остатки без причины
Проводится и формирует движения
Ошибка проведения или пустые движения
Отсутствуют или все обработаны вручную
В документах ссылки на «Объект не найден»
Что важно запомнить
Любой ремонт начинается с резервной копии. Порядок действий: очистка кэша → chdbfl.exe → тестирование и исправление с безопасными настройками → выгрузка в dt → восстановление из архива. После ремонта обязательно проверьте остатки и проведение документов, а для профилактики настройте регулярное копирование.
Частые вопросы
Можно ли чинить базу, пока пользователи работают?
Нет. Chdbfl, тестирование и исправление, выгрузка в dt требуют монопольного доступа. Запуск ремонта при активных сеансах либо заблокируется, либо приведёт к рассогласованию данных. Завершите все сеансы через консоль кластера или список активных пользователей.
Chdbfl сообщила, что ошибок нет, но база всё равно не работает. Что делать?
Физическая структура файла цела, значит проблема логическая или в кэше. Очистите кэш, затем запустите тестирование и исправление в конфигураторе. Если ошибка указывает на конкретную таблицу, попробуйте выгрузку-загрузку через dt.
Чем отличается выгрузка в dt от копирования файла 1Cv8.1CD?
Копирование файла — мгновенный снимок, включая возможные повреждения. Выгрузка в dt читает данные через механизмы платформы и сохраняет их в переносимом формате; при загрузке структура таблиц создаётся заново, что само по себе лечит часть дефектов. Для архивации лучше держать оба варианта.
После тестирования и исправления пропали документы. Можно ли вернуть?
Если был выбран режим «Удалять объект», данные удалены безвозвратно — восстановить их можно только из резервной копии, сделанной до ремонта. Именно поэтому копия перед любыми операциями обязательна, а режим «Создавать объекты» предпочтительнее.
База лежит на сетевом диске и периодически портится. В чём причина?
Файловые базы 1С крайне чувствительны к обрывам сети во время записи. Перенесите базу на локальный диск компьютера, который работает как сервер, либо переведите её в клиент-серверный режим на СУБД — это устранит саму причину повреждений.
Когда стоит привлекать специалиста, а не чинить самостоятельно?
Если база клиент-серверная и повреждена на уровне СУБД, если chdbfl и тестирование не помогли, а архивной копии нет, или если в базе критичные финансовые данные без актуального бэкапа. В таких случаях ошибка любителя обходится дороже услуг восстановления.