Ремонт повреждённой информационной базы 1С 8.3: от проверки файла до отката на копию

Если база 1С повреждена, исправить её в 1С 8.3 можно в четыре хода: сделать копию в текущем состоянии, проверить физическую целостность (для файловой базы — утилитой chdbfl.exe, для SQL — средствами СУБД), запустить в Конфигураторе Администрирование → Тестирование и исправление и только при неудаче откатиться на резервную копию. Порядок важен: каждый следующий шаг грубее предыдущего.

Чаще всего проблема проявляется сообщениями Файл базы данных поврежден, Ошибка формата потока, внезапным вылетом при открытии конкретного документа или отчёта. Почти всегда базу удаётся вернуть без потери данных, если не перепутать порядок действий.

Шаг 0. Диагностика: что сломано на самом деле

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

Задайте себе четыре вопроса:

• 🖥 Ошибка у всех пользователей или у одного? Если у одного — почти наверняка виноват локальный кэш или профиль. Базу пока не трогайте.
• 📄 Ошибка на всём или на одном объекте? Если падает только один документ, справочник или отчёт, повреждение, скорее всего, точечное — в данных или индексе одной таблицы.
• 🔌 Что было перед сбоем? Отключение электричества, падение сети во время записи, принудительное завершение процесса 1cv8.exe, обновление конфигурации , которое прервали.
• 🗄 Какая база? Файловая (папка с файлом 1Cv8.1CD) или клиент-серверная (MS SQL, PostgreSQL). От этого зависит набор инструментов.

Тип базы виден в окне запуска: выделите её в списке, внизу появится строка подключения. File="D:\Bases\Buh" — файловая, Srvr="server1";Ref="buh" — клиент-серверная.

Полезно заглянуть и в журнал регистрации (Конфигуратор → Администрирование → Журнал регистрации, или в пользовательском режиме через функции для технического специалиста). Отфильтруйте события по уровню «Ошибка» за последние дни: часто там видно, на каком объекте и в какое время начались сбои.

Подготовка: копия «как есть» и монопольный режим

Перед любым ремонтом сохраните базу в текущем, пусть и сломанном, состоянии. Ремонтные инструменты могут удалить испорченные объекты безвозвратно — без копии назад дороги не будет.

Как сделать копию:

1. Попросите всех пользователей выйти из базы. Проверьте, что в Конфигуратор → Администрирование → Активные пользователи никого не осталось.
2. Файловая база: скопируйте всю папку базы целиком (не только 1Cv8.1CD) на другой диск. Делайте это при закрытой базе, иначе копия может оказаться такой же битой.
3. Клиент-серверная база : сделайте полный бэкап средствами СУБД (в MS SQL — через Management Studio, в PostgreSQL — pg_dump).
4. Дополнительно попробуйте выгрузку Конфигуратор → Администрирование → Выгрузить информационную базу в файл .dt. Если выгрузка прошла — отлично, у вас есть ещё одна страховка. Если упала с ошибкой, это тоже информация: повреждение есть в данных.

Тестирование и исправление требует монопольного доступа к базе. В клиент-серверном варианте установите блокировку начала сеансов в консоли администрирования кластера: свойства информационной базы, флажок блокировки начала сеансов, время начала и сообщение для пользователей.

Проверка физической целостности: файловая и SQL-база

Файловая база: утилита chdbfl.exe

chdbfl.exe — штатная утилита платформы для проверки физической целостности файла 1Cv8.1CD. Она лежит в каталоге bin установленной платформы, например C:\Program Files\1cv8\8.3.24.1342\bin\chdbfl.exe (номер версии у вас свой).

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

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

Утилита работает только на уровне файла: восстанавливает структуру страниц и таблиц. Логику данных (битые ссылки, остатки) она не проверяет — для этого дальше нужен Конфигуратор.

💡 Если база лежит на сетевом диске, скопируйте её на локальный диск и проверяйте там. По сети chdbfl.exe работает медленно, а обрыв связи посреди исправления только добавит проблем.

Клиент-серверная база на MS SQL

На стороне MS SQL Server целостность проверяют командой DBCC CHECKDB. Запуск в Management Studio:

DBCC CHECKDB ('buh') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Если команда вернула пустой результат — физически база на SQL цела, ищите проблему на уровне 1С. Если есть ошибки, начните с самого мягкого варианта исправления:

ALTER DATABASE buh SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('buh', REPAIR_REBUILD);
ALTER DATABASE buh SET MULTI_USER;

REPAIR_REBUILD перестраивает индексы и не удаляет данные. Режим REPAIR_ALLOW_DATA_LOSS удаляет повреждённые страницы вместе с записями — применяйте его только на копии и только если иначе база не поднимается.

Клиент-серверная база на PostgreSQL

Встроенной команды, аналогичной DBCC CHECKDB, в PostgreSQL нет. Практичный способ найти битые таблицы — пробная выгрузка pg_dump в отдельный файл: при чтении повреждённой страницы она остановится с ошибкой и назовёт таблицу. Дальше проверьте диск сервера и журнал PostgreSQL, а логику данных — тестированием в Конфигураторе.

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

Главный инструмент ремонта на уровне 1С. Работает для файловых и клиент-серверных баз одинаково.

Откройте базу в режиме Конфигуратора и выберите Администрирование → Тестирование и исправление. В окне есть набор проверок и режим: «Тестирование» (только отчёт) или «Тестирование и исправление».

Как действовать:

1. Первый проход — только «Тестирование». Включите реиндексацию, логическую и ссылочную целостность, пересчёт итогов. Посмотрите отчёт в окне служебных сообщений.
2. Разберите найденное. Если найдены ссылки на несуществующие объекты, выберите действие: создавать объекты, очищать ссылки или не изменять.
3. Второй проход — «Тестирование и исправление». Для битых ссылок безопаснее «Создавать объекты»: программа создаст объекты-заглушки, и вы потом увидите, где были ссылки. «Очищать ссылки» молча обнулит реквизиты в документах — восстановить, что там было, станет сложно.
4. Реструктуризацию включайте, только если обычный проход не помог. На большой базе она идёт часами.

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

💡 Для клиент-серверной базы тестирование тоже нагружает СУБД. Запускайте его там, где у сервера есть запас по диску: временные таблицы при реструктуризации занимают место, сопоставимое с размером самой большой таблицы.

Выгрузка и загрузка через .dt

Отдельный приём, который часто вылечивает файловую базу , когда тестирование ошибок не находит, а сбои остаются:

1. Выгрузите базу в .dt.
2. Создайте новую пустую базу в другой папке.
3. Откройте её в Конфигураторе и выполните Администрирование → Загрузить информационную базу.

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

Очистка кэша и временных файлов

Многие ошибки, похожие на порчу базы, на деле живут в локальном кэше пользователя. Классический пример — Ошибка формата потока после обновления конфигурации у одного-двух сотрудников.

Способ 1. Параметр запуска. В окне запуска выделите базу, нажмите «Изменить», дойдите до последней страницы и в поле дополнительных параметров запуска впишите:

/ClearCache

Запустите базу. После успешного входа параметр можно убрать.

Способ 2. Вручную. Закройте все сеансы 1С на этом компьютере и удалите папки с длинными именами-идентификаторами (GUID) в двух каталогах:

%APPDATA%\1C\1cv8
%LOCALAPPDATA%\1C\1cv8

Служебные файлы вроде 1cv8strt.pfl и списка баз ibases.v8i (он лежит в %APPDATA%\1C\1CEStart) не трогайте — там настройки и список информационных баз. Папки с GUID платформа пересоздаст при следующем запуске.

Серверный кэш. В клиент-серверном варианте сеансовые данные хранятся в каталоге кластера (srvinfo). Чистить его можно только при остановленной службе агента сервера 1С.

Если не помогло: восстановление из резервной копии

Когда ни chdbfl.exe, ни тестирование не возвращают базу к жизни, остаётся откат на последнюю исправную копию.

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

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

💡 Если бэкап MS SQL вёлся в полной модели восстановления с журналом транзакций, базу можно поднять на момент за несколько минут до сбоя. Для этого нужны полный бэкап и непрерывная цепочка бэкапов журнала после него.

Профилактика: как не доводить базу до ремонта

Почти все физические повреждения файловой базы — следствие внезапного обрыва записи. Отсюда и меры.

• 🔋 ИБП на компьютере или сервере, где лежит база. Отключение питания во время записи — самая частая причина порчи 1Cv8.1CD.
• 📶 Не работайте с файловой базой по Wi-Fi и через VPN. Обрыв связи посреди записи портит файл. Для удалённой работы — терминальный доступ или веб-публикация.
• 🛡 Исключения в антивирусе. Добавьте в исключения папку базы и каталоги кэша. Проверка файла на лету может блокировать запись.
• 👥 Число пользователей. Если в файловой базе одновременно работает больше 5–10 человек, задумайтесь о переходе на клиент-серверный вариант: он устойчивее к сбоям.
• 💾 Регулярные копии. Ежедневная копия плюс копия перед каждым обновлением конфигурации. Раз в месяц проверяйте, что копия разворачивается.
• 🧰 Плановое тестирование. Раз в квартал — тестирование без исправления, чтобы поймать проблему до того, как она станет аварией.

Настройка журнала регистрации

Журнал регистрации помогает понять, что произошло перед сбоем. Настройка: Конфигуратор → Администрирование → Настройка журнала регистрации.

1. Уровень — «Регистрировать ошибки, предупреждения и информацию» или «Регистрировать все». Первый вариант даёт меньший объём файлов.
2. Включите разделение журнала по периодам (например, по месяцу), чтобы старые части можно было архивировать.
3. Проверьте, что на диске с базой есть свободное место: журнал растёт быстро, а переполненный диск сам по себе вызывает сбои записи.

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