Резервные копии 1С: что делать, если база не открывается

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

Почему файловая база 1С повреждается

Файловая база — это один файл 1Cv8.1CD, в котором лежат все таблицы разом, и клиент пишет в него напрямую по сети или локально. Любой сбой в момент записи оставляет файл в противоречивом состоянии: часть страниц записана, часть нет, внутренние индексы указывают в пустоту. Клиент-серверный вариант и облако этой уязвимости лишены, потому что записью управляет СУБД с журналом транзакций.

• Обрыв сетевой связи. База лежит в общей папке на сервере или на компьютере главбуха, пользователь работает по сети. Пропал Wi-Fi, коммутатор ушёл в перезагрузку, кабель задели ногой — транзакция обрывается на середине.
• Переполнение диска. База растёт вместе с журналом регистрации и временными файлами. Когда свободного места не остаётся, 1С физически не может дописать страницу и падает.
• Некорректное завершение работы. Отключение питания, синий экран, снятие процесса 1cv8.exe через диспетчер задач, перезагрузка сервера по расписанию обновлений Windows в момент, когда в базе работают люди.
• Ограничение размера. Технологический предел файловой базы — 4 Гб на одну таблицу, но реальные проблемы начинаются раньше: базу от 8–10 Гб пора переводить на клиент-серверный вариант или в облако.
• Антивирус и облачные диски. Файл базы в синхронизируемой папке клиент синхронизации начинает копировать прямо во время записи, а антивирус — блокировать. Оба сценария заканчиваются одинаково.

Первые пятнадцать минут: чего нельзя делать

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

1. Выгнать всех пользователей и убедиться, что процесс 1cv8.exe не висит ни на одном компьютере. Работа в базе на время разбора прекращается полностью.
2. Скопировать файл 1Cv8.1CD обычным копированием в отдельную папку с датой в названии. Это не резервная копия, а фиксация текущего состояния: все дальнейшие эксперименты проводятся на копии.
3. Проверить свободное место на диске и освободить объём минимум вдвое больше размера базы — инструменты лечения создают временные файлы.
4. Записать точный текст ошибки со скриншотом. Формулировка отличает повреждение файла от проблемы с лицензией, платформой или правами доступа к сетевой папке.
5. Найти последнюю резервную копию и посмотреть её дату. Это сразу показывает цену худшего сценария: сколько документов придётся ввести заново.
6. Если своего технического специалиста нет — передать копию файла в поддержку и не тратить время на эксперименты вслепую.

Штатные инструменты восстановления

← таблицу можно прокрутить вбок →

Порядок применения именно такой: сначала физическая целостность файла, затем логика данных, затем полная пересборка. chdbfl.exe лежит в каталоге платформы по пути вида C:\Program Files\1cv8\8.3.xx.xxxx\bin, запускается двойным щелчком, в окне указывается путь к файлу 1Cv8.1CD. Первый прогон делайте без галочки «Исправлять обнаруженные ошибки»: отчёт покажет масштаб, и если ошибок тысячи, восстановление из копии даст более здоровую базу, чем починка. На базе в несколько гигабайт проверка идёт от десяти минут до часа. Когда база открывается хотя бы в конфигураторе, работает более тонкий инструмент — «Администрирование — Тестирование и исправление информационной базы»: реиндексация таблиц, проверка логической и ссылочной целостности, пересчёт итогов, сжатие таблиц. В блоке «При наличии ссылок на несуществующие объекты» для первого прогона выбирайте «Не изменять» и режим «Только тестирование» — сначала читаем отчёт, потом решаем.

Файл dt — это выгрузка данных без служебных структур хранения, обычно в несколько раз компактнее исходного 1Cv8.1CD. Пересборка базы через выгрузку и загрузку в пустую базу лечит целый класс мелких аномалий и заодно даёт архив, который можно передать специалисту или перевезти в облако — как это устроено целиком, разобрано в материале про перенос данных 1С. Но делается она руками, а значит забывается ровно тогда, когда нужнее всего, и резервное копирование как процесс не заменяет. Есть и ситуации, когда лечение — просто потеря времени: chdbfl.exe не читает заголовок файла, после исправления документы теряют табличные части, объём базы упал в разы. Доверять такой базе нельзя. Развернуть вчерашнюю копию и ввести документы за день заново — это несколько часов работы, а обнаружить через месяц пропавшие движения по регистру — это пересдача отчётности. Обязанность обеспечивать сохранность регистров бухгалтерского учёта не менее пяти лет закреплена в статье 29 402-ФЗ, и «база сломалась» её не отменяет.

Как устроены резервные копии в 1С:Фреш

В сервисе 1С:Фреш копии делает сам сервис: раз в сутки — системную копию всех приложений, а также ежедневные, ежемесячные и ежегодные копии тех приложений, в которых работали. По умолчанию хранятся 3 последние ежедневные копии (можно увеличить до 10), 2 ежемесячные (до 6) и 3 ежегодные. Перед рискованной операцией можно сделать свою копию по требованию — сервис хранит 10 последних.

• Копии хранятся на серверах провайдера сервиса в зашифрованном виде.
• Любую копию можно скачать из личного кабинета — это ваша собственная копия, храните где считаете нужным.
• Восстановить приложение из копии владелец абонента может сам: из копии создаётся новое приложение, а текущее остаётся для сверки.
• Копирование входит в подписку и не является отдельной статьёй расходов — что ещё включено, видно на странице тарифы, а обязательства по доступности и сохранности данных описаны в разделе гарантии.

Пошагово — в статье «Резервная копия в 1С:Фреш: как сделать, скачать и восстановить».

Регламент бэкапов для коробочной версии

Как проверить, что копия рабочая

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

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