Администрирование · 13 мин
Как вылечить базу 1С после сбоя
Пошаговое руководство по лечению базы 1С: тестирование и исправление, утилита chdbfl.exe, восстановление из резервной копии, очистка кэша и типичные ошибки.
Повреждение информационной базы 1С — одна из самых частых аварий в работе бухгалтерии и отдела продаж. База перестаёт открываться, выдаёт ошибку «Файл базы данных повреждён», зависает при обращении к конкретным документам или показывает «битые» ссылки вида «Объект не найден». Причины почти всегда одинаковы: внезапное отключение электричества, сбой жёсткого диска, разрыв сетевого соединения при файловом режиме работы, аварийное завершение процесса или переполнение диска во время записи.
Хорошая новость в том, что большинство повреждений лечится штатными средствами платформы без привлечения сторонних сервисов. В арсенале администратора есть три основных инструмента: режим «Тестирование и исправление» в конфигураторе, утилита chdbfl.exe для файловых баз и восстановление из резервной копии. Для клиент-серверных баз на SQL добавляются средства СУБД. Правильный выбор зависит от типа базы и характера повреждения.
Главное правило при любой аварии — не пытаться «лечить» единственную копию базы. Любое исправление потенциально необратимо: механизмы восстановления могут удалить повреждённые объекты вместе с данными. Поэтому первый шаг всегда один — снять копию в текущем состоянии, и только потом приступать к лечению.
Первые действия при сбое: что сделать до лечения
Прежде чем запускать любые механизмы исправления, зафиксируйте текущее состояние. Для файловой базы скопируйте файл 1Cv8.1CD целиком в отдельный каталог — это ваша страховка на случай, если автоматическое лечение ухудшит ситуацию. Для клиент-серверной базы сделайте выгрузку через конфигуратор, если он ещё открывается, либо снимите резервную копию средствами СУБД.
Далее убедитесь, что с базой никто не работает. Тестирование и исправление требует монопольного доступа: завершите сеансы пользователей через консоль кластера или просто попросив всех выйти, проверьте, что не осталось фоновых заданий. В файловом режиме достаточно убедиться, что рядом с файлом базы нет открытых сеансов и файл не заблокирован.
Запишите точный текст ошибки и момент её появления. «База не открывается вообще», «падает при открытии конкретного документа» и «выдаёт ошибки при проведении» — это три разных сценария с разными методами лечения. Скриншот ошибки и запись в технологическом журнале существенно упростят диагностику.
Тестирование и исправление в конфигураторе
Основной штатный инструмент — режим «Тестирование и исправление». Откройте конфигуратор, перейдите в меню «Администрирование» → «Тестирование и исправление». В появившемся окне выберите проверки и режим работы. Для большинства случаев достаточно трёх пунктов: реиндексация таблиц, проверка логической целостности и проверка ссылочной целостности.
Режим выбирайте «Тестирование и исправление», а не «Только тестирование», если цель — именно вылечить базу. В разделе обработки ошибок ссылочной целостности есть три варианта: создавать объекты, очищать ссылки или не изменять. Вариант «создавать объекты» безопаснее: платформа создаст объекты-заглушки вместо битых ссылок, и вы потом разберётесь с ними вручную. Вариант «очищать ссылки» удалит упоминания потерянных объектов — это быстрее, но необратимо стирает следы проблемы.
Процесс на большой базе может занять от десятков минут до нескольких часов, прерывать его нельзя. После завершения внимательно прочитайте протокол в окне сообщений: там перечислены все найденные и исправленные ошибки. Сохраните этот список — он подскажет, какие данные могли пострадать.
- 1Сделайте копию файла базы или выгрузку .dt
- 2Завершите все сеансы пользователей и фоновые задания
- 3Откройте конфигуратор → Администрирование → Тестирование и исправление
- 4Отметьте реиндексацию, проверку логической и ссылочной целостности
- 5Выберите режим «Тестирование и исправление», для битых ссылок — «Создавать объекты»
- 6Дождитесь завершения и сохраните протокол ошибок
- 7Проверьте работу базы: открытие, проведение документов, отчёты
Утилита chdbfl.exe для файловых баз
Если файловая база повреждена настолько, что не открывается даже конфигуратор, на помощь приходит утилита chdbfl.exe. Она находится в каталоге bin установленной платформы, внутри папки с номером версии. Утилита работает напрямую с файлом 1Cv8.1CD, минуя механизмы платформы, поэтому справляется с физическими повреждениями структуры файла.
Запустите chdbfl.exe, укажите путь к файлу 1Cv8.1CD, отметьте флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить». Утилита сначала проверит физическую целостность структуры базы, затем при включённом флажке попытается исправить найденные дефекты. После её работы обязательно прогоните «Тестирование и исправление» в конфигураторе — chdbfl чинит физику файла, но не проверяет логику данных.
Важное ограничение: утилита работает только с файловыми базами. Для клиент-серверных баз на MS SQL, PostgreSQL или Oracle она бесполезна — там физическую целостность проверяют средствами самой СУБД.
Очистка кэша и лечение «призрачных» ошибок
Значительная часть «повреждений базы» на деле оказывается повреждением кэша метаданных на клиентском компьютере. Симптомы характерные: ошибка возникает только у одного пользователя или только на одном компьютере, а у остальных база работает нормально. В этом случае лечить саму базу не нужно — достаточно очистить локальный кэш.
Самый простой способ — удалить базу из списка в окне запуска 1С и добавить её заново с тем же путём. Платформа создаст новый каталог кэша. Альтернатива — вручную удалить содержимое каталогов кэша в профиле пользователя: в папках AppData\Roaming\1C\1cv8 и AppData\Local\1C\1cv8 найдите каталоги с длинными буквенно-цифровыми именами (это идентификаторы баз) и удалите те, что относятся к проблемной базе.
Если после очистки кэша у конкретного пользователя ошибка осталась, а у других всё работает — проверьте права доступа, настройки его клиентского приложения и версию платформы на его компьютере. Расхождение версий платформы между клиентом и сервером тоже даёт похожие симптомы.
Как выбрать действие
Восстановление из резервной копии
Когда лечение не даёт результата или исправление унесло слишком много данных, единственный надёжный путь — откат на резервную копию. Восстановите последнюю рабочую копию в отдельный каталог, не затирая повреждённую базу: она ещё понадобится как источник данных за период с момента бэкапа до сбоя.
Дальше предстоит самая трудоёмкая часть — перенос разницы. Откройте обе базы параллельно (если повреждённая хоть как-то открывается) и составьте список документов, созданных после даты резервной копии. Для типовых конфигураций удобно использовать обработку «Выгрузка и загрузка данных XML» с диска ИТС: она переносит данные между идентичными конфигурациями по отбору. Если повреждённая база не открывается совсем, разницу придётся вводить вручную по бумажным документам, выпискам и письмам.
После восстановления обязательно сверьте ключевые показатели: оборотно-сальдовую ведомость, остатки по складам и взаиморасчёты с контрагентами на дату сбоя. Расхождения покажут, какие именно данные потеряны.
Клиент-серверные базы: особенности лечения
Для баз на MS SQL Server физическую целостность проверяют командой DBCC CHECKDB. Сначала запустите её без параметров исправления, чтобы оценить масштаб повреждений. Режимы REPAIR_REBUILD и особенно REPAIR_ALLOW_DATA_LOSS применяйте только после полного бэкапа на уровне СУБД: второй режим, как следует из названия, допускает потерю данных ради восстановления структуры.
После исправления на уровне СУБД всё равно выполните «Тестирование и исправление» в конфигураторе: СУБД чинит физику страниц и индексов, но ничего не знает о логической и ссылочной целостности объектов 1С. Только связка двух инструментов даёт полную картину.
Для PostgreSQL ситуация сложнее: штатного аналога CHECKDB нет, поэтому при подозрении на физические повреждения обычно делают выгрузку через pg_dump — если выгрузка проходит без ошибок, физика скорее всего в порядке, и проблему ищут на уровне платформы 1С.
Проверка результата и профилактика
Лечение считается завершённым только после контрольной проверки. Откройте базу в пользовательском режиме, пройдитесь по основным разделам: журналы документов, справочники, отчёты. Проведите несколько документов за разные периоды, сформируйте оборотно-сальдовую ведомость и сверьте итоги с теми, что были до сбоя, если есть чем сверять. Проверьте объекты-заглушки, созданные при исправлении ссылочной целостности, — их нужно либо заполнить данными, либо заменить на корректные объекты.
Профилактика сводится к трём вещам. Первое — регулярные резервные копии с проверкой их восстанавливаемости: копия, которую никто не проверял, может оказаться битой. Второе — источник бесперебойного питания для сервера и корректное завершение работы: большинство повреждений файловых баз происходит именно при внезапном обрыве питания или сети. Третье — мониторинг состояния дисков и свободного места: переполнение диска во время записи в базу даёт тяжёлые повреждения.
Как проверить результат лечения
База и списки открываются без ошибок
Ошибки при открытии отдельных документов или журналов
Документы разных видов проводятся штатно
Ошибки проведения, сообщения об отсутствующих объектах
Итоги совпадают с данными до сбоя
Расхождения в итогах, пустые обороты
Заглушки найдены и обработаны
В данных остались объекты с именами вида «Объект не найден»
Частые вопросы
Можно ли запустить тестирование и исправление, пока пользователи работают?
Нет, режим требует монопольного доступа к базе. Если запустить его при активных сеансах, конфигуратор либо откажется стартовать, либо принудительно завершит сеансы (при соответствующей настройке), что чревато потерей несохранённых данных пользователей. Запланируйте лечение на нерабочее время и заранее предупредите сотрудников.
Тестирование и исправление удалило часть документов. Что делать?
Немедленно прекратите работу в этой базе. Возьмите копию, которую вы делали перед лечением, и восстановите из неё данные. Если копии не было — ищите последнюю резервную копию. Документы, удалённые механизмом исправления, восстановить из вылеченной базы уже нельзя: они физически удалены из файла. Именно поэтому копия перед лечением — обязательный шаг, а не рекомендация.
Чем отличается выгрузка в .dt от копирования файла 1Cv8.1CD?
Копирование файла — это побайтовый слепок базы, включая все повреждения и кэш. Выгрузка в .dt — логическая выгрузка данных через платформу: она возможна, только если база открывается, и при повреждениях может оборваться с ошибкой. Для страховки перед лечением надёжнее копия файла; .dt удобен для переноса базы между компьютерами и смены режима работы.
База лечится очень долго, это нормально?
Да, для больших баз тестирование и исправление может идти несколько часов, а на многогигабайтных файловых базах — сутками. Ускорить процесс можно, выполняя его локально на быстром диске (SSD), а не по сети. Если прогресс не меняется сутками и активности диска нет — процесс мог зависнуть, но перед принудительным завершением убедитесь, что у вас есть копия базы.
Как уменьшить риск повторного повреждения базы?
Ключевые меры: ИБП для сервера и сетевого оборудования, запрет работы с файловой базой по Wi-Fi и через нестабильные сетевые подключения, контроль свободного места на диске, регулярные проверяемые резервные копии и своевременное обновление платформы. Для растущих файловых баз с несколькими пользователями стоит рассмотреть переход на клиент-серверный режим — он существенно устойчивее к сбоям.
Помогут ли сторонние программы восстановления данных?
Специализированные сервисы восстановления баз 1С существуют и иногда вытаскивают данные из баз, с которыми не справились штатные средства. Но гарантий они не дают, а передача базы третьим лицам означает передачу всех коммерческих и персональных данных компании. К этому варианту стоит прибегать только когда исчерпаны штатные инструменты и нет приемлемой резервной копии.
Что важно запомнить
Лечение базы 1С всегда начинается с копии в текущем состоянии. Основные инструменты — «Тестирование и исправление» в конфигураторе и chdbfl.exe для файловых баз; ошибки у одного пользователя чаще всего лечатся очисткой кэша. Если исправление не помогло — восстанавливайтесь из резервной копии и переносите разницу документов. Результат считается достигнутым только после проверки проведения документов и сверки отчётов.