Что на самом деле портит информационную базу 1С и как её вернуть

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

Типичная картина: в пятницу вечером бухгалтер проводит закрытие месяца , в офисе моргает свет, а в понедельник 1С пишет Файл базы данных поврежден. Причин порчи семь, и у каждой свой способ восстановить базу без потерь.

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

Файловая база 1С — это один файл 1Cv8.1CD. Платформа постоянно пишет в него: проводит документы, пересчитывает итоги, обновляет индексы. Если запись оборвалась на середине, в файле остаётся недописанная страница.

Что приводит к обрыву:

• 🔌 отключение питания без ИБП;
• 🖱 принудительное закрытие 1С через диспетчер задач во время проведения или загрузки данных;
• 💻 «жёсткое» выключение ноутбука кнопкой, сон или гибернация с открытой базой;
• 🌐 обрыв сети, если база лежит на другом компьютере.

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

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

1. Закройте 1С у всех пользователей.
2. Скопируйте папку с базой целиком в другое место. Работайте дальше с оригиналом, копию не трогайте.
3. Запустите утилиту chdbfl.exe — она лежит в папке bin установленной платформы, например C:\Program Files\1cv8\8.3.xx.xxxx\bin\. Укажите путь к 1Cv8.1CD, сначала запустите проверку без исправления, затем с галочкой исправления.
4. Откройте базу в Конфигураторе: Администрирование → Тестирование и исправление. Отметьте проверку логической и ссылочной целостности, реиндексацию и пересчёт итогов.

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

Неудачное обновление конфигурации

Обновление — второй по частоте способ испортить базу. Само по себе оно безопасно, если соблюдать порядок. Ломают базу отступления от него.

Самый опасный момент — обновление конфигурации базы данных, когда платформа перестраивает таблицы. На крупной базе это занимает от минут до часов. Закрыть Конфигуратор в этот момент — значит получить базу, которая не открывается ни в старой, ни в новой версии.

Безопасный порядок обновления

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

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

Файловый вариант рассчитан на небольшое число пользователей. Когда его кладут на общий сетевой ресурс и подключают десять человек по Wi-Fi, база начинает страдать.

Почему это опасно:

• 📶 каждое рабочее место пишет в общий файл напрямую по сети, и обрыв у одного пользователя может повредить файл для всех;
• 🗂 механизм «Автономные файлы» Windows или синхронизация облачного диска (Яндекс Диск, OneDrive и подобные) копируют 1Cv8.1CD по частям и могут перезаписать его устаревшей версией;
• 🧱 сетевое хранилище (NAS) с агрессивным кешированием подтверждает запись раньше, чем данные реально попали на диск;
• 🐢 медленная сеть растягивает транзакции, и окно для повреждения увеличивается.

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

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

Транзакции и блокировки: когда 1С ломает данные изнутри

Здесь база физически цела, но данные в ней противоречат друг другу. Такую порчу называют логической.

Как это происходит:

• 🔒 долгая транзакция в клиент-серверной базе прерывается снятием сеанса или рабочего процесса rphost — СУБД откатывает изменения, но внешние обработки, которые писали данные порциями в отдельных транзакциях, оставляют базу «наполовину»;
• 🧩 самописная обработка меняет регистры напрямую, в обход проведения документов, — итоги расходятся с документами;
• 🛠 программист правит таблицы прямо в СУБД через SQL-запросы — платформа об этих изменениях не знает;
• ⏳ взаимоблокировки при одновременном проведении документов одних и тех же товаров приводят к массовым ошибкам, пользователи начинают «обходить» их ручными корректировками.

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

Как исправить

1. Сделайте резервную копию.
2. В Конфигураторе запустите Администрирование → Тестирование и исправление с проверкой ссылочной целостности. Для битых ссылок выберите вариант создания объектов или очистки ссылок осознанно: создание сохраняет связи, очистка теряет их.
3. Пересчитайте итоги.
4. Перепроведите документы за проблемный период штатной обработкой групового перепроведения.

Для серверных баз физическую целостность проверяют средствами СУБД. Для MS SQL Server это команда:

DBCC CHECKDB ('ИмяБазы') WITH NO_INFOMSGS;

Без параметров исправления она только проверяет и безопасна. Исправляющие режимы DBCC CHECKDB могут удалить данные, поэтому их запускают только с резервной копией и пониманием последствий.

Вирусы, шифровальщики и чужие руки

Для 1С самая реальная угроза из этой группы — шифровальщик. Он не «ломает» базу в привычном смысле, а шифрует 1Cv8.1CD, .dt-выгрузки и резервные копии на всех доступных дисках.

Как вредоносное ПО добирается до базы:

• 🖥 подбор пароля к удалённому рабочему столу, открытому в интернет на стандартном порту;
• 📧 вложение в письме, запущенное пользователем с правами администратора;
• 💾 резервные копии лежат на том же сервере или на сетевом диске, доступном с заражённого компьютера.

Отдельная бытовая проблема — антивирус. Если он проверяет 1Cv8.1CD или файлы СУБД «на лету», запись тормозит, а иногда файл блокируется на время проверки. Папки с базами и временные файлы платформы лучше добавить в исключения проверки в реальном времени.

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

Что защищает:

• резервные копии в месте, куда нельзя записать с рабочего сервера: отдельное хранилище с доступом только на запись новых файлов или копия вне офиса;
• закрытый из интернета RDP, доступ через VPN;
• отдельный пользователь 1С на каждого сотрудника и блокировка учётной записи в день увольнения;
• включённый журнал регистрации с хранением за достаточный период.

Права доступа пользователей: порча руками бухгалтера

Пользователь с полными правами может нанести базе больше вреда, чем вирус. И делает это не со зла.

Что чаще всего происходит:

• 🗑 удаление помеченных объектов без проверки — вместе с ненужным элементом справочника уходят документы, где он использовался, или появляются битые ссылки;
• 📅 перепроведение закрытых периодов, по которым уже сдана отчётность;
• 🔧 запуск внешних обработок «из интернета», которые массово меняют реквизиты;
• 📥 загрузка данных из другой базы без предварительной проверки сопоставления.

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

Удаление помеченных объектов запускайте вне рабочего времени и после резервной копии: обработка показывает, какие объекты не удалось удалить из-за ссылок на них, и это повод разобраться, а не удалять «через силу».

Аппаратные сбои: когда виновато железо

Если база повреждается регулярно, без видимых причин, ищите проблему в оборудовании.

Работать с базой на диске, который «сыплется», нельзя: каждая попытка исправления может добить его окончательно. Сначала снимите копию файлов на исправный носитель, потом лечите копию.

Признаки повреждения и порядок спасения

Повреждённая база не всегда сообщает об этом прямо. Вот что стоит считать тревожными сигналами.

Если исправление не помогло

Порядок действий, от безопасного к радикальному:

1. Восстановить из свежей резервной копии. Самый надёжный путь. Потеряете только данные с момента копии.
2. Выгрузить в .dt и загрузить обратно в новую пустую базу. Выгрузка часто «обходит» повреждённые служебные структуры. Если выгрузка падает с ошибкой, повторите её после chdbfl.exe.
3. Перенести данные в чистую базу через универсальный обмен или выгрузку-загрузку данных между конфигурациями. Долго, но спасает справочники и документы, когда сам файл безнадёжен.
4. Обратиться к специалисту по восстановлению. Чем меньше попыток «полечить» вы сделали до этого, тем выше шанс.

Минимальная гигиена, которая закрывает почти все перечисленные причины:

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