Сразу договоримся: “Формат потока” почти всегда означает, что 1С попыталась прочитать кусок данных, а там каша. Как будто вы открыли книгу, а на 73-й странице внезапно пошел рецепт борща и два листа смяты.
Хорошая новость: базу часто реально вернуть к жизни.
Плохая: если начать хаотично нажимать кнопки, можно сделать хуже.
Дальше будет четкий порядок действий. Не “как в учебнике”, а как делают люди, которым нужно вернуть работу бухгалтерии сегодня, а не когда-нибудь.
В первую минуту: что точно НЕ делать
- Не пытайтесь открыть базу снова и снова “на удачу”.
- Это как дергать за провод у мигающего роутера: иногда кажется, что помогает, но чаще просто добиваешь.
- Не лечите “на оригинале”.
- Починка без копии это ремонт телефона молотком. Иногда “включился”, но ненадолго.
- Не позволяйте всем подряд “просто зайти посмотреть”.
- Один человек чинит, остальные ждут. Иначе получится командная работа по ухудшению ситуации.
Быстро понять, какая у вас база: файловая или SQL
Это важно, потому что “рецепт” разный.
Файловая база
В списке баз путь выглядит примерно так: \\server\share\... и внутри лежит файл 1Cv8.1CD.
Обычно это база на сетевой папке или на локальном диске.
Клиент-сервер (SQL)
Подключение идет через сервер 1С/кластер, а не напрямую к файлу. Там чаще всплывают другие причины и другая диагностика.
Если сомневаетесь, 9 раз из 10 у малого бизнеса это как раз файл 1Cv8.1CD на шаре. Та самая “экономия”, которая потом превращается в ночные переписки.
Если база файловая (1Cv8.1CD)
Блок 1. Сначала спасаем “тело”, потом лечим “голову”
Шаг 1. Сделайте копию файла базы
Прямо копию 1Cv8.1CD.
И да, иногда это 8 ГБ. Иногда 42 ГБ. Иногда 120 ГБ и вы внезапно узнаете, что гигабайты умеют идти пешком.
Копировать нужно, когда все вышли из базы.
Если база лежит на сетевой папке и люди заходят “по привычке”, проще временно закрыть доступ или переименовать папку. Жестко? Зато честно.
Мини-кейс из типовых: база 27 ГБ, свет моргнул, утром “формат потока”. Сделали копию, починили на копии, оригинал оставили как музей ошибок. Сэкономили себе возможность отката, когда позже выяснилось, что у клиента еще и диск начал сыпаться.
Шаг 2. Проверьте, не “железо” ли устроило праздник
Очень часто причина не в 1С, а в том, что:
- сеть дернулась на секунду
- диск словил ошибки
- сервер перезагрузили в момент записи
- на шару прилетел антивирус “проверить файл прямо сейчас”
Если база на сетевой шаре, “формат потока” может прилететь просто потому, что связь с сервером у пользователя похожа на разговор по телефону в лифте.
Блок 2. Лечим аккуратно, по слоям
Шаг 3. Запускаем “Тестирование и исправление” в Конфигураторе
Это самый спокойный и часто самый результативный метод.
Порядок простой:
- открыть базу в Конфигураторе
- Администрирование → Тестирование и исправление
Как выбирать галочки?
Не “все подряд”. Лучше в 2 захода.
Первый заход (самый безопасный):
- проверка целостности
- исправление ссылок (если есть такая опция)
- аккуратные исправления без фанатизма
Второй заход (если первый не помог или помог частично):
- более глубокие проверки
- пересчет итогов, если нужно
По времени это может быть по-разному:
на базе 10-20 ГБ иногда укладывается в 30-90 минут.
на базе 60+ ГБ может тянуться 4-8 часов. Да, неприятно. Но часто дешевле, чем “пересоздать все руками”.
Шаг 4. Если Конфигуратор не открывается, пробуем chdbfl
Это утилита для проверки файловой базы.
Она не волшебная, но иногда делает ровно то, что нужно: приводит базу в состояние “хотя бы открыть и дальше лечить штатно”.
Ключевое: запускать на копии, не на оригинале.
Кейс из частых: база не открывалась ни тонким, ни толстым, Конфигуратор падал на старте. chdbfl прогнался, выдал пару неприятных сообщений, но после этого Конфигуратор уже запустился, и дальше база починилась через тестирование.
Шаг 5. План “переезд”: выгрузка/загрузка (dt)
Если база открывается хотя бы в Конфигураторе, выгрузка в dt и загрузка в новую базу иногда работает лучше любой “хирургии”.
Это как переехать из квартиры, где “что-то странно пахнет”, в новую, забрав нужное и выкинув мусор по дороге.
Блок 3. Когда проще восстановиться, чем чинить
Если у вас есть нормальный бэкап, часто быстрее:
- восстановить базу
- потерять максимум день работы (или меньше)
- и уже потом разбираться, почему случилось
Но тут есть ловушка, которую многие узнают слишком поздно:
“Бэкап есть” не равно “бэкап рабочий”.
Самый грустный сценарий выглядит так:
- копировали базу “просто файлом”, пока в ней работали
- копия есть, но внутри она битая
- и это выясняется только в день аварии
Поэтому золотое правило сопровождения: периодически проверять восстановление. Пусть раз в неделю. Пусть на тестовой машине. Иначе бэкап это не спасательный круг, а рисунок спасательного круга.
Если база на SQL (клиент-сервер)
Тут “формат потока” чаще связан с проблемами на уровне СУБД, диска, индексов, или “сервер резко выключили”.
Базовая логика:
- Сделать резервную копию SQL базы (даже если она подозрительная).
- Проверить состояние базы средствами SQL.
- Если есть повреждения и есть нормальный бэкап, часто разумнее восстановиться, чем пытаться “дочинить” живьем.
Почему так? Потому что SQL-ремонт иногда похож на склейку вазы из 300 осколков. Вроде можно, но потом кто-то дотронется, и она снова рассыпется.
Почему это случается: 4 причины, которые я вижу чаще всего
1) Файловая база на сетевой папке, пользователей больше 5
Сеть моргнула, кто-то открыл “толстым клиентом”, кто-то печатал, кто-то провел документ.
И вот данные записались “на половину вдоха”.
Если пользователей 10-20 и база живет на шаре, это как возить стекло в тележке по брусчатке. Когда-то разобьется.
2) Резко выключили сервер
Самый классический сюжет: “а что, он завис, я просто перезагрузил”.
Именно в эту секунду 1С могла писать данные.
3) Копирование базы во время работы
Люди искренне думают, что “копия файла” и “резервная копия” одно и то же.
Нет. Копия файла в момент записи часто превращается в полуфабрикат.
4) Антивирус/резервное ПО вмешивается не вовремя
Он “проверил” файл базы, когда 1С в него писала.
И все, как в плохой комедии: вы лечите, оно снова ломается.
План на первые 15 минут (если нужно прям сейчас)
- Остановить пользователей.
- Сделать копию (файл 1Cv8.1CD или SQL backup).
- Понять тип базы.
- Для файла: Конфигуратор → тестирование и исправление.
- Если не открывается: chdbfl на копии.
- Если есть рабочий бэкап: восстановление часто быстрее и спокойнее.
Как снизить шанс повторения (без фанатизма)
- Бэкапы по расписанию: минимум ежедневно, а лучше 2-4 раза в день для активных баз.
- Раз в неделю проверять восстановление. Да, это скучно. Но скука тут лечит убытки.
- Не держать файловую базу на сетевой шаре, если база крупная и пользователей много.
- ИБП для сервера: дешевле, чем один аварийный выезд и потерянный день.
- Следить за диском и ошибками, не ждать “пока совсем умрет”.
