Чем восстановить базы 1С: рабочие способы и порядок действий

Повреждение информационной базы 1С — одна из самых неприятных ситуаций для бухгалтера и администратора: программа не запускается, выдаёт ошибку формата потока, «отсутствует файл базы данных» или база открывается, но документы не проводятся. Хорошая новость в том, что в большинстве случаев базу можно восстановить штатными средствами, если действовать в правильном порядке и не усугубить ситуацию поспешными действиями.

Выбор инструмента зависит от трёх факторов: формата базы (файловая или клиент-серверная на SQL), наличия резервной копии и характера повреждения. Самый надёжный способ — откат на резервную копию. Если копии нет, используются утилита тестирования и исправления, проверка физической целостности файла 1Cv8.1CD, а для SQL-баз — средства СУБД.

Прежде чем что-либо исправлять, сделайте копию текущего состояния базы — просто скопируйте папку с базой или файл 1Cv8.1CD в отдельное место. Любое «лечение» выполняется на копии, а не на единственном экземпляре данных. Это главное правило, которое сохранит возможность отступить, если выбранный способ не сработает.

Как определить тип повреждения и формат базы

Сначала выясните, с чем имеете дело. Откройте список баз в стартовом окне 1С, выделите базу и посмотрите путь внизу окна. Если это папка на диске или сетевом ресурсе — база файловая, её ядро — файл 1Cv8.1CD. Если указан сервер и имя базы — база клиент-серверная, данные хранятся в MS SQL Server, PostgreSQL или другой СУБД.

Характер ошибки подсказывает причину. «Ошибка формата потока» при открытии чаще связана с повреждением кэша или отдельных таблиц. «Файл базы данных повреждён» с указанием пути к 1Cv8.1CD означает физическое повреждение файла — типично после внезапного отключения питания или сбоя сети при работе по сети. Ошибки вида «could not read block» или упоминание SQL указывают на проблему на стороне СУБД.

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

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

Если у вас есть актуальная резервная копия, это почти всегда лучший вариант: вы получаете гарантированно целостную базу с известной потерей данных — только за период между копией и сбоем. Для файловых баз копия обычно представляет собой либо архив папки с базой, либо выгрузку в файл с расширением dt.

Чтобы восстановить базу из dt-файла, откройте конфигуратор, создайте новую пустую базу (или откройте ту, которую восстанавливаете, — но безопаснее новую), затем выберите «Администрирование → Загрузить информационную базу» и укажите dt-файл. После загрузки обновите конфигурацию базы данных, если программа попросит, и проверьте вход в пользовательском режиме.

Если копия — это просто архив папки, распакуйте её в новый каталог и подключите базу через список информационных баз кнопкой «Добавить». Для SQL-баз восстановление выполняется средствами СУБД: в MS SQL Server — через SQL Server Management Studio, задача «Restore Database» из bak-файла, после чего база подключается в консоли кластера 1С или напрямую в списке баз.

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

Штатный инструмент «Тестирование и исправление» устраняет логические повреждения: битые ссылки, ошибки в индексах, повреждённые таблицы. Запускается он в конфигураторе через меню «Администрирование → Тестирование и исправление» и работает только в монопольном режиме — все пользователи должны выйти из базы.

В открывшемся окне отметьте проверки: «Реиндексация таблиц», «Проверка логической целостности», «Проверка ссылочной целостности». Для начала выберите вариант «Тестирование» без исправления — он покажет масштаб проблем, не меняя данные. Затем запустите «Тестирование и исправление». Для крупных баз процесс занимает от десятков минут до нескольких часов.

Обратите внимание на настройку обработки битых ссылок внизу окна. Вариант «Не изменять» самый безопасный: объекты с потерянными ссылками останутся как есть. «Создавать объекты» восстановит заглушки, «Очищать ссылки» и «Удалять объект» — агрессивные варианты, которые могут привести к потере записей. Начинайте с «Не изменять», оцените отчёт и только потом решайте, нужна ли более жёсткая обработка.

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

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

Если конфигуратор не открывает базу вообще и выдаёт «Файл базы данных повреждён», логическое тестирование недоступно — нужно сначала восстановить физическую целостность файла. Для этого в составе платформы 1С поставляется утилита chdbfl.exe, находящаяся в каталоге bin установленной версии платформы.

Запустите chdbfl.exe, укажите путь к файлу 1Cv8.1CD, установите флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить». Утилита проверит структуру файла и исправит повреждённые страницы. Работайте только с копией файла: исправление необратимо, а при серьёзных повреждениях часть таблиц может быть утеряна.

После успешной проверки chdbfl база обычно открывается в конфигураторе. Не останавливайтесь на этом — обязательно прогоните «Тестирование и исправление», потому что физически восстановленный файл может содержать логические ошибки и битые ссылки.

C:\Program Files\1cv8\<версия>\bin\chdbfl.exe — указать файл 1Cv8.1CD, включить «Исправлять обнаруженные ошибки»

Восстановление клиент-серверной базы на SQL

Для баз на MS SQL Server инструменты другие. Сначала проверьте целостность базы средствами самой СУБД командой DBCC CHECKDB в режиме проверки без исправления — она покажет, есть ли повреждения и какие объекты затронуты. Результат определяет дальнейшую стратегию.

Если повреждения есть, предпочтительный путь — восстановление из последнего бэкапа SQL с последующим применением журналов транзакций, если они настроены: это минимизирует потерю данных. Вариант DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS применяйте только как крайнюю меру: он физически удаляет повреждённые страницы вместе с данными, и объём потерь заранее непредсказуем.

После восстановления на уровне СУБД дополнительно выполните «Тестирование и исправление» в конфигураторе 1С — СУБД гарантирует целостность на уровне страниц и индексов, но не знает о логике ссылок 1С. Также проверьте, что у учётной записи службы агента сервера 1С сохранились права на восстановленную базу.

Очистка кэша и восстановление без инструментов

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

Самый простой способ — удалить базу из списка в стартовом окне и добавить её заново с тем же путём: при этом создаётся новая папка кэша. Альтернатива — вручную удалить содержимое папок с кэшем в профиле пользователя (каталоги вида %APPDATA%\1C\1cv8 с подпапками по идентификаторам баз). После этого ошибки формата потока у конкретного пользователя обычно исчезают.

Если ошибка наблюдается у всех пользователей файловой базы, попробуйте ещё один безопасный приём до запуска исправления: сделайте выгрузку в dt из конфигуратора («Администрирование → Выгрузить информационную базу») и загрузите её в новую пустую базу. Выгрузка-загрузка пересобирает структуру данных и нередко устраняет мелкие повреждения.

Проверка результата и типичные ошибки

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

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

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

Когда обращаться к специалистам и как не допустить повторения

Самостоятельное восстановление оправдано, когда есть резервная копия, повреждение логическое и у вас есть время на проверки. Обращайтесь к специалистам по восстановлению данных, если: база единственная и копий нет, chdbfl и тестирование не помогли, повреждён жёсткий диск или RAID-массив, либо потеряны критичные данные за большой период. Чем меньше операций выполнено с повреждённым носителем до обращения, тем выше шансы на успех.

Чтобы ситуация не повторилась, настройте регулярное резервное копирование: для файловых баз — ежедневную выгрузку в dt или копирование папки по расписанию, для SQL-баз — регламентные бэкапы средствами СУБД. Периодически проверяйте, что копии реально разворачиваются: непроверенная копия не считается копией.

Дополнительные меры: источник бесперебойного питания для сервера и компьютера с файловой базой, отказ от работы с файловой базой по сети Wi-Fi, исключение папок 1С из активной проверки антивируса с сохранением периодического сканирования, мониторинг свободного места на дисках.

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