Повреждение информационной базы 1С: диагностика, исправление и откат на копию

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

Частая ошибка — считать базу «сломанной» по первому же сообщению. Ошибка формата потока или зависание на заставке часто вызывает испорченный локальный кэш, а не данные. Кэш чистится за минуту. А «лечить» исправную базу тестированием с удалением объектов — это как раз способ её испортить.

С чего начать: копия и разбор симптомов

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

Не запускайте исправление, пока не сделали копию повреждённой базы.

Порядок первых действий:

1. 🛑 Попросите всех пользователей выйти из базы. Для серверной базы проверьте сеансы в консоли кластера и предупредите людей заранее: принудительное завершение сеансов оборвёт их несохранённую работу.
2. 📁 Файловая база: скопируйте весь каталог базы целиком, а не только 1Cv8.1CD. Рядом лежит каталог 1Cv8Log с журналом регистрации, он ещё понадобится.
3. 🗄️ Серверная база: сделайте полный бэкап средствами СУБД (MS SQL Server, PostgreSQL). Выгрузка .dt из повреждённой базы может не пройти, поэтому на неё не рассчитывайте.
4. 📝 Запишите точный текст ошибки, время её появления и действие, после которого она возникла.

Как отличить повреждение данных от других сбоев

Кэш клиента лежит в профиле пользователя, в каталогах %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Подкаталоги с длинными именами-идентификаторами можно удалить при закрытой 1С. Другой вариант — запустить клиент с параметром /ClearCache. Если после этого база открылась, повреждения данных не было.

Логи: что произошло с базой и когда

Перед ремонтом выясните причину. Иначе после восстановления база сломается снова.

Журнал регистрации

Если база открывается хотя бы в Конфигураторе, журнал смотрят через Администрирование → Журнал регистрации. В типовых конфигурациях на БСП он доступен и в пользовательском режиме: Администрирование → Обслуживание → Журнал регистрации.

Что искать:

• 🔍 события с уровнем «Ошибка» за последние часы перед сбоем;
• 🔍 обновление конфигурации , загрузку .dt, реструктуризацию — частые точки отказа;
• 🔍 массовое удаление объектов: кто, когда, какие элементы;
• 🔍 аварийные завершения сеансов подряд у нескольких пользователей.

Если база не открывается совсем, журнал всё равно доступен на диске, в каталоге 1Cv8Log. Скопируйте его в каталог пустой файловой базы и откройте журнал уже там.

Журналы Windows и СУБД

Физические повреждения обычно идут снаружи. Проверьте журнал событий Windows («Система») на сервере или компьютере с базой: ошибки диска, внезапные перезагрузки, отключения питания.

Для серверной базы смотрите журнал ошибок СУБД. Сообщения о повреждённых страницах или ошибках ввода-вывода означают, что проблема в хранилище. Тестирование в 1С её не решит.

💡 Технологический журнал платформы включают файлом logcfg.xml. Он нужен, когда сбой воспроизводится, но причина неясна. Для разового повреждения обычно хватает журнала регистрации и системных журналов.

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

Это встроенный инструмент платформы для логических ошибок: битых ссылок, неверных итогов, повреждённых индексов. Запускается из Конфигуратора: Администрирование → Тестирование и исправление. Нужен монопольный доступ, поэтому все пользователи должны выйти.

Какие проверки включать

Безопасный порядок запуска

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

Запуск из командной строки

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

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "D:\Bases\Buh" /N "Администратор" /P "пароль" /IBCheckAndRepair -ReIndex -RecalcTotals -TestOnly /Out "D:\Logs\check.txt"

Ключ -TestOnly включает режим «Только тестирование». Уберите его, чтобы утилита исправляла ошибки. Полный список ключей /IBCheckAndRepair смотрите в документации к платформе.

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

Если тестирование не помогло или испортило данные, откатывайтесь на копию. Это самый надёжный путь, и он часто быстрее, чем часы исправлений.

Какую копию брать

• 📦 .dt — выгрузка через Конфигуратор. Подходит для любого варианта базы.
• 📦 Копия каталога с 1Cv8.1CD — для файловой базы, если файл копировали при закрытой базе.
• 📦 Бэкап СУБД — для серверной базы, позволяет точечное восстановление.

Берите последнюю копию, сделанную до первых признаков сбоя. Время сбоя вы уже нашли по журналам.

Загрузка .dt

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

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

В типовых конфигурациях на БСП для файловой базы есть встроенный механизм: Администрирование → Обслуживание → Резервное копирование и восстановление. Через него же восстанавливают копии, сделанные по расписанию.

Как вернуть данные после копии

Между копией и сбоем пользователи что-то вводили. Эти данные можно восстановить так:

1. Откройте журнал регистрации повреждённой базы (из сохранённого каталога 1Cv8Log).
2. Отфильтруйте события изменения данных за период от копии до сбоя.
3. Составьте список документов и справочников, введённых или изменённых за это время.
4. Если повреждённая база открывается, перенесите их выгрузкой. Если нет — введите заново по первичке.

Журналы транзакций и откат на нужную минуту

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

MS SQL Server

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

RESTORE DATABASE [buh_restore] FROM DISK = N'D:\Backup\buh_full.bak'
  WITH NORECOVERY, MOVE N'buh' TO N'D:\Data\buh_restore.mdf',
  MOVE N'buh_log' TO N'D:\Data\buh_restore_log.ldf';
RESTORE LOG [buh_restore] FROM DISK = N'D:\Backup\buh_log.trn'
  WITH STOPAT = N'2026-10-06T14:55:00', RECOVERY;

Логические имена файлов (buh, buh_log) у вас будут свои. Посмотрите их командой RESTORE FILELISTONLY для файла бэкапа. Восстанавливайте в базу с новым именем, затем зарегистрируйте её в кластере 1С как отдельную информационную базу и проверьте.

PostgreSQL

Аналог — непрерывное архивирование WAL и восстановление на момент времени (PITR) с параметром recovery_target_time. Механизм работает, только если архивирование WAL настроили заранее. Если в журналах только ежедневные дампы pg_dump, откат возможен только на момент дампа.

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

Файловая и клиент-серверная база: в чём разница при восстановлении

Файловая база

Все данные лежат в одном файле 1Cv8.1CD. Он чаще всего повреждается при обрыве записи: отключили питание, упала сеть до общей папки, антивирус заблокировал файл во время записи.

Главный инструмент — утилита chdbfl.exe. Она лежит в каталоге bin установленной платформы. Порядок:

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

chdbfl.exe чинит физическую структуру файла, а Конфигуратор — логическую. Поэтому они идут парой и именно в таком порядке.

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

Данные хранит СУБД, и физические повреждения проверяют её средствами:

• 🗄️ MS SQL Server: DBCC CHECKDB для базы. Запускайте в нерабочее время, проверка нагружает сервер.
• 🗄️ PostgreSQL: проверка индексов расширением amcheck, в новых версиях — утилитой pg_amcheck.

Тестирование и исправление в Конфигураторе для серверной базы тоже работает. Но на большой базе оно идёт часами, поэтому выделите для него ночь или выходной.

Отдельный случай — повреждение кэша сервера 1С, а не данных. Симптом: ошибки у всех пользователей сразу, при этом проверка СУБД чистая. Кэш сервера очищают при остановленной службе агента сервера 1С. Остановка службы обрывает все сеансы всех баз на этом сервере — делайте это вне рабочего времени и после предупреждения пользователей.

Как не допустить повторного повреждения

После восстановления устраните причину. Иначе всё повторится через неделю.

• 🔌 ИБП для компьютера или сервера с файловой базой. Обрыв питания при записи — классическая причина повреждения 1Cv8.1CD.
• 🌐 Файловую базу не держите в общей папке через нестабильную сеть или Wi-Fi. Если в базе работают больше 3-5 человек, переходите на клиент-серверный вариант или веб-публикацию.
• 🛡️ Добавьте каталог базы в исключения антивируса: проверка файла во время записи вызывает блокировки и сбои.
• 💾 Проверьте место на диске. Заполненный диск обрывает запись и портит файл.
• 🔁 Обновляйте конфигурацию только после свежей выгрузки .dt.

Резервное копирование, которое реально спасает

1. Ежедневная копия: .dt, копия каталога файловой базы при закрытой 1С или полный бэкап СУБД.
2. Для серверной базы — бэкап журнала транзакций каждые 15-60 минут, в зависимости от того, сколько работы вы готовы потерять.
3. Храните копии минимум на двух носителях, один из них — вне сервера с базой.
4. Срок хранения — не меньше 2-4 недель. Логическую порчу иногда замечают через несколько дней.
5. Раз в месяц пробуйте восстановить копию в тестовую базу. Непроверенная копия может оказаться пустой или битой.

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