Короткий ответ

Если файловая база (обычно 1Cv8.1CD) выдаёт «файл базы данных поврежден», не запускайте chdbfl.exe по боевому файлу и не открывайте конфигуратор «на исправление» без копии. Сначала исключите пользователей, скопируйте каталог информационной базы целиком на другой том, проверьте, что копия читается, и только на копии гоняйте тестирование/исправление и chdbfl. Предпочтительный путь — откат к последней консистентной копии, а не «вылечить дырки» в единственном файле.

Это не SQL-база Accounting на SQL01. Если у вас клиент-сервер, этот сценарий не про MSSQLSERVER. Файловый вариант часто живёт на \\fileserver\1C\Accounting\.

Симптомы и как отличить

Типичная картина:

  • сообщение о повреждении файла БД или «ошибка формата потока»;
  • база открывалась утром, после отключения электричества на NAS — нет;
  • конфигуратор падает на старте, предприятие — тоже;
  • файл 1Cv8.1CD резко меньше вчерашнего backup.

Отличия:

Что видноЭто не «порча 1CD»Куда
Только один ПК, у других база открываетсякэш/платформа1С не запускается
Клиент-сервер Srvr="SRV-1C"кластер/SQLсервер 1С, SQL
Файл на месте, нет прав на шаруSMB/ACLдоступ к каталогу
После неудачного обновления конфигурацииоткат обновленияобновление ошибкой

Возможные причины

  1. Отключение питания NAS/сервера при активных сеансах.
  2. Копия «по расписанию» поверх открытого 1Cv8.1CD (robocopy живого файла).
  3. Диск/RAID с latent error, шара отвалилась по сети.
  4. Антивирус поймал файл на середине записи.
  5. Закончилось место на томе — файл обрезан.
  6. Ручное копирование базы в проводнике, пока бухгалтер в документе.
  7. Редко: физический бэд блок без backup.

Диагностика

1. Это точно файловая база

В списке баз: каталог, не Srvr=. В каталоге должны быть 1Cv8.1CD, часто 1Cv8Log, иногда 1Cv8.1CL.

Get-ChildItem '\\fileserver\1C\Accounting' | Format-Table Name, Length, LastWriteTime

2. Кто держит файл

Пока файл открыт, не копируйте «на живую» как единственную копию и не запускайте chdbfl.

# на файловом сервере, если есть права
Get-SmbOpenFile | Where-Object { $_.Path -like '*Accounting*1Cv8*' }

Отключите пользователей штатно (выйти из 1С), не reboot всех ПК сразу без предупреждения.

3. Есть ли годная копия

Проверьте время последнего backup каталога, VSS-снимок тома, ленту. Откройте копию в отдельном каталоге тестовой платформой 8.3 той же сборки.

4. Место и целостность тома

Get-Volume -FilePath '\\fileserver\1C\Accounting'

Нулевой свободный объём — сначала диск, иначе любое «лечение» снова обрежет файл.

Решение

Сценарий A. Есть проверенный backup

  1. Сохраните текущий повреждённый каталог (переименуйте в Accounting-broken-дата), даже если он «плохой» — вдруг из него вытащат кусок.
  2. Восстановите backup в новый каталог, не поверх единственной копии.
  3. Подключите тестовой строкой, пройдите журнал, проведите контрольный документ.
  4. Только после проверки переключайте пользователей на восстановленный каталог.

Как делать копии дальше: резервирование файловой 1С.

Сценарий B. Backup нет, остался только боевой файл

  1. Все сеансы закрыты, SMB-открытия нет.
  2. Скопируйте 1Cv8.1CD и весь каталог на другой диск: Accounting-copy.
  3. На копии запустите chdbfl.exe из каталога той же платформы 8.3:
# пример пути; подставьте свою сборку 8.3
& 'C:\Program Files\1cv8\8.3.23.1782\bin\chdbfl.exe'

В GUI укажите файл копии. Сначала проверка без исправления. Исправление — только если копия оригинала сохранена отдельно.

  1. Если chdbfl «исправил» — откройте эту копию в 1С, выгрузите DT на всякий случай, сверните итоги не в первый же час. Боевой путь меняйте, когда есть подтверждение, что документы на месте.

Сценарий C. Тестирование и исправление в конфигураторе

Конфигуратор → Тестирование и исправление — тоже только по копии. Не ставьте все галочки «исправить» на проде за один проход в пятницу вечером без выгрузки.

Сценарий D. Пора уходить с файловой

Если база уже на десятки гигабайт и несколько бухгалтеров — планируйте перенос в клиент-сервер на SRV-1C + SQL01. Это не лечение повреждения, но снимает класс аварий «NAS моргнул». См. перенос базы.

Как проверить, что проблема устранена

  • База открывается тонким/толстым клиентом той же 8.3.
  • Журнал регистрации читается, последние документы на месте (сверьте номера с бумагой/сканами).
  • Создайте копию «после лечения» и уберите пользователей на неё только после сверки.
  • Свободное место на томе есть, антивирус не блокирует 1CD.

Если не помогло

  • chdbfl не открывает файл — остаётся только более старый backup или коммерческое восстановление файлов, не «утилиты с форумов».
  • Открывается, но расходятся регистры — восстановление на дату + ручной ввод, не бесконечный chdbfl.
  • Повреждён только журнал 1Cv8Log — иногда база жива; не удаляйте 1CD из-за лога.
  • Подозрение на шифровальщик — не чините 1CD, ищите чистую копию offline.

Профилактика

  • Консистентный backup: пользователи out или VSS тома, не robocopy открытого 1CD. Процедура — в статье про резервирование файловой 1С.
  • ИБП на NAS и хост.
  • Не класть единственный 1CD на десктоп главбуха.
  • Мониторинг места и SMART/RAID шары.
  • Лимит: файловая база — для малых объёмов; дальше SQL.

FAQ

Можно ли запустить chdbfl, пока один пользователь «просто смотрит отчёт»?

Нет. Файл открыт — риск добить базу. Все вышли, копия, потом утилита на копии.

Конфигуратор предлагает тестирование. Это безопаснее chdbfl?

Тоже пишет в файл. Без копии — тот же класс риска. Порядок: копия → тест на копии.

Восстановили вчерашний backup, сегодняшний день потерян. Что дальше?

Это RPO. Не пытайтесь «склеить» битый сегодняшний 1CD с вчерашним вслепую. Ввод документов за день из первички дешевле второй порчи.

Нужен ли SQL Server для лечения файловой базы?

Нет для самого ремонта 1CD. SQL появляется, только если вы переносите базу в клиент-сервер после аварии.

Почему копия из проводника «на всякий случай» не открывается?

Скопировали во время работы. Такая копия часто уже повреждена. Нужен простой или снимок тома.