Что повреждает файл базы 1С и как не допустить потери данных

Повредить базу 1С проще всего не злым умыслом, а неосторожностью: выдернули питание во время записи документа, сняли процесс 1cv8.exe через диспетчер задач, скопировали файл *.1CD прямо во время работы пользователей. Файловая база особенно хрупкая — это один большой файл, и любой обрыв записи в него оставляет структуру в несогласованном состоянии.

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

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

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

У файлового варианта все данные лежат в одном файле 1Cv8.1CD в каталоге базы. Платформа пишет в него напрямую, поэтому сбой записи бьёт сразу по всей базе. Выгрузка *.DT — это не рабочая база, а дамп: архив, из которого базу разворачивают заново.

В клиент-серверном варианте данные хранит СУБД (PostgreSQL или MS SQL), а 1С общается с ней через рабочие процессы кластера. Здесь за целостность отвечает транзакционный механизм СУБД, и «порвать» базу обрывом записи куда труднее — но её по-прежнему можно повредить неверным обслуживанием СУБД, несовместимой платформой или шифровальщиком.

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

Обрыв записи: отключение питания и снятие процесса

Это причина номер один. Платформа в момент проведения документа или реструктуризации пишет в *.1CD несколько связанных блоков. Если запись прервать на середине — файл остаётся в состоянии, которое платформа при следующем старте уже не считает целым.

Чем прерывают запись чаще всего:

• ⚡ пропало электричество, а источника бесперебойного питания нет;
• 🖥 зависший сеанс «убили» через Диспетчер задач → снятие 1cv8.exe;
• 🔌 сетевую папку с базой отключили, пока в ней работали (файловая база по сети — отдельный риск);
• 💾 диск переполнился ровно в момент записи, и блок записался не до конца.

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

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

Ручная правка *.1CD в hex-редакторе

Открыть файл базы в hex-редакторе и что-то в нём поменять — самый быстрый способ превратить рабочую базу в мусор. Формат *.1CD закрытый, внутри — согласованные между собой заголовки, таблицы и индексы с контрольными зависимостями.

Любое изменение байтов нарушает эти зависимости: платформа при открытии проверяет структуру и либо не открывает базу вовсе, либо открывает с непредсказуемым поведением — пропадают документы, «едут» итоги, вылетают формы.

Отдельно: не пытайтесь «подчистить» размер базы, обнулив куски файла. Уменьшить *.1CD без потери данных нельзя простым обрезанием — для этого есть сжатие таблиц в штатном тестировании.

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

Опасные параметры chdbfl и «Тестирования и исправления»

Инструменты, которые базу лечат, при неверных настройках её же и калечат. Два основных:

1. chdbfl.exe — утилита проверки физической целостности файловой базы, лежит в каталоге bin установленной платформы. Запускается при закрытой базе. Если поставить галочку исправления ошибок без свежей резервной копии, утилита может удалить повреждённые, но ещё частично читаемые записи — и данные уйдут безвозвратно.

2. Тестирование и исправление в Конфигураторе: Администрирование → Тестирование и исправление информационной базы. Опасность в комбинации галочек:

   • при Проверке логической целостности с режимом удаления платформа выкинет объекты, которые сочтёт битыми;
   • при Проверке ссылочной целостности выбор Удалять ссылки вычистит ссылки на «потерянные» объекты;
   • Реструктуризация таблиц перестраивает хранилище целиком и на повреждённой базе может усугубить проблему.

Правильный порядок: закрыть базу для всех → скопировать файл *.1CD → запускать проверку сначала в режиме только тестирования, без исправления → смотреть журнал → и лишь потом, по конкретной ошибке, включать нужное исправление.

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

Тестирование и исправление, реструктуризация и загрузка *.DT требуют монопольного доступа к базе — то есть на это время в базе не должно быть других сеансов.

Разрастание файловой базы до предела

Файловый формат не рассчитан на безграничный рост. У классического формата *.1CD размер отдельной таблицы ограничен (исторически — 4 ГБ на таблицу), и при приближении к пределу база начинает вести себя непредсказуемо: замедляется, выдаёт ошибки при записи крупных объектов, в худшем случае повреждается при попытке дозаписи.

Разрастание разгоняют:

• 📎 присоединённые файлы, которые хранятся внутри базы, а не в томах на диске;
• 🧾 многолетняя история без архивирования закрытых периодов;
• 🔁 неудалённые помеченные объекты и «мусор» после обменов.

Что с этим делать:

• присоединённые файлы вынести в тома хранения файлов на диске (Администрирование → Настройки работы с файлами), чтобы они не раздували *.1CD;
• регулярно запускать свёртку базы по старым периодам — она заменяет горы старых документов входящими остатками;
• выполнять сжатие таблиц в тестировании и исправлении, чтобы освободить место после удаления данных;
• при устойчивом росте и нескольких пользователях — переходить на клиент-серверный вариант, где таких ограничений формата нет.

Подмена cf/cfe и несовместимые версии платформы

Базу можно сделать неработоспособной не трогая *.1CD — через конфигурацию и платформу.

Подмена файлов конфигурации и расширений. Если загрузить в базу чужой или битый файл конфигурации (*.cf) или расширения (*.cfe), не совпадающий со структурой данных, при обновлении конфигурации базы платформа перестроит хранилище под новую структуру — и несовпадение приводит к потере или порче данных. Загрузка *.cfe и шаг Обновить конфигурацию базы данных — разные операции: сначала расширение подключается, затем применяется к базе. Расширения, к слову, появились в платформе 8.3.6.

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

Без действующей лицензии платформа базу просто не запустит (исключение — учебная версия с её ограничениями) — это не повреждение, а блокировка запуска, данные при этом целы.

Вирусы, шифровальщики и внешние угрозы

Файл *.1CD — обычный файл на диске, и для шифровальщика он такая же мишень, как документы Word. Разница в последствиях: зашифрованная рабочая база означает остановку учёта.

Чем base портят извне:

• 🦠 шифровальщики (ransomware) — шифруют *.1CD и резервные копии, если те лежат рядом на том же диске;
• 🧨 вирусы-инжекторы — дописывают себя в исполняемые и иногда в прочие файлы, нарушая структуру;
• 🌐 атаки на открытый наружу сервер СУБД — если порт PostgreSQL/MS SQL торчит в интернет без ограничений.

Защита тут не про 1С, а про гигиену:

• антивирус с актуальными базами на сервере и рабочих местах;
• резервные копии на отдельном носителе или в сетевом хранилище, отключённом от рабочей машины (шифровальщик не должен дотянуться до копий);
• каталог сервера СУБД не публиковать в интернет напрямую, доступ — через VPN или по белому списку адресов;
• не работать в базе из-под учётной записи с правами администратора ОС без нужды.

Как защитить базу: рабочий регламент

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

Если база уже повреждена, не спешите «лечить» в рабочем файле. Сначала определите, что именно сломалось, — отсюда зависит способ восстановления.

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