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

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

Как понять, что база действительно повреждена

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

• Ошибки доступа и лицензирования — «не обнаружена лицензия», сообщения о сервере, занятых сеансах. Данные целы, проблема организационная.
• Ошибка формата потока — указывает на проблему с чтением данных информационной базы. Причины — от безобидного битого кэша до реального повреждения файла базы.
• Ошибка SDBL — в клиент-серверном варианте часто возникает после обновления и реструктуризации; лечится очисткой кэша, тестированием и исправлением или выгрузкой-загрузкой в .dt.
• Ошибка при открытии одного документа или отчёта — обычно локальная проблема одной записи, а не всей базы.
• Полный отказ запуска, зависание на старте, аварийное завершение — требует диагностики, нередко связано именно с целостностью данных.

Ошибка формата потока пугает сильнее всего, но вот что важно: она далеко не всегда означает катастрофу. Её вызывают повреждённые временные файлы и кэш, активные сеансы с разными версиями платформы, расширения, а в самом неприятном случае — повреждение файла базы. И да, взломанные версии платформы тоже входят в список причин. Так что сначала — диагностика, потом — действия.

Первый час: что делать и что не делать

Сделать сразу:

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

Не делать категорически:

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

Первое правило восстановления: сначала копия того, что сломалось. Чинить то, что не скопировано, — всё равно что оперировать без анестезии: может и получится, но зачем.

Шаг ноль: кэш, а не катастрофа

Прежде чем хвататься за резервную копию, проверьте самое дешёвое. Ошибку формата потока при входе в базу очень часто устраняет очистка кэша платформы на компьютере пользователя — папки в %appdata%\1C\1cv8 и локальной аналогичной. Это занимает две минуты, не трогает данные и снимает заметную долю «аварий». Заодно убедитесь, что у всех пользователей одна версия платформы: смесь версий в активных сеансах — ещё один известный источник этой ошибки.

Помогло — отлично, записываем в журнал и живём дальше. Не помогло — переходим к тяжёлой артиллерии.

Восстановление из резервной копии: основной путь

Если у компании есть регулярная и проверенная резервная копия — это основной и самый надёжный путь. Восстановление возвращает базу в рабочее состояние на момент бэкапа; сколько времени оно займёт — зависит от размера базы и от того, где лежит архив: от десятков минут до нескольких часов.

Варианты по порядку:

1. Файловая база, копия папки. Самый простой случай: подменить повреждённый файл 1Cv8.1CD файлом из резервной копии.
2. Копия в формате .dt. Загружается через Конфигуратор («Администрирование» → «Загрузить информационную базу») или через режим предприятия: «Администрирование» → «Обслуживание» → «Резервное копирование и восстановление». Помните: при загрузке .dt текущие данные базы полностью заменяются данными из архива. Полностью. Поэтому — см. пункт про копию текущего состояния.
3. Клиент-серверная база. Восстановление делается средствами СУБД из её резервной копии; .dt здесь запасной вариант, а не основной.

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

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

Если резервной копии нет или она старая: тестирование и исправление

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

• База должна быть в монопольном режиме: все сеансы завершены, работает только администратор. Иначе получите ошибку «не удаётся получить монопольный режим» и ничего не произойдёт.
• Процедура предложит варианты действий с ссылками на несуществующие объекты: создать объекты-заменители, очистить ссылки или не менять. Выбор влияет на то, как будут выглядеть документы после исправления, — не ставьте галочки наугад.
• Тестирование исправляет логические ошибки в структуре базы, но не творит чудес, если файл физически повреждён на уровне диска.
• Для клиент-серверной базы с ошибкой SDBL дополнительный вариант — выгрузка и загрузка в .dt; это известный способ «пересобрать» структуру.

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

Файловая база и клиент-сервер: разные сбои, разные действия

В клиент-серверном варианте (1С плюс SQL-сервер) логика та же, но выполнять её нужно на уровне СУБД — и без администратора с опытом работы с базами данных риск усугубить повреждение выше. Проявляется проблема тоже по-разному:

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

Бухгалтер замечает такие странности первым. Документ не проводится со второго раза, отчёт «иногда» выдаёт ошибку — это не повод пожать плечами, это повод проверить базу сегодня, пока она ещё открывается.

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

Сценарий: сбой диска в ночь перед сдачей отчётности

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

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

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

Декларацию по НДС не интересует, что у вас сломался диск. Её интересует 25-е число.

Профилактика: как не оказаться в этой ситуации

• Автоматическое резервное копирование по расписанию, а не «когда вспомнили».
• Правило 3-2-1: три копии данных, на двух разных носителях, одна из них — вне офиса. Копия на том же диске, где рабочая база, погибает вместе с ней.
• Регулярная проверка: резервная копия должна открываться, и данные в ней должны быть корректными. Испорченный архив, который никто не проверял, в день сбоя не спасёт — он просто отнимет ещё час.
• Плановое тестирование и исправление для активно работающих многопользовательских баз — как профилактика, а не как реанимация.
• Выделенный сервер для 1С, если компания выросла за пределы одного офисного компьютера. Диск рабочей станции под столом бухгалтера — худшее место для базы, в которой лежит весь ваш учёт.

Что делаем мы и чем это отличается

Штатный бухгалтер, у которого ломается база, в девяти случаях из десяти не знает, с чего начать. Либо сидит без учёта несколько дней в ожидании ИТ-специалиста, либо действует сам — и сжигает те самые критичные первые часы. Дешёвый ИТ-подрядчик, который обслуживает сервер «по заявкам», приезжает через день-два, когда база уже добита повторными попытками открыть её. А потом разводит руками: «Ну, бэкапов-то не было». Так это ведь и была его работа — чтобы они были.

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

Чек-лист: действия при сбое базы 1С

• ☐ Остановить попытки открыть базу до диагностики причины.
• ☐ Сохранить копию текущего (повреждённого) файла базы, прежде чем что-либо менять.
• ☐ Очистить кэш платформы и проверить, что у всех одна версия 1С.
• ☐ Найти дату и время последней рабочей резервной копии.
• ☐ Восстановить базу из резервной копии, если она есть и достаточно свежая.
• ☐ При отсутствии свежего бэкапа — тестирование и исправление в монопольном режиме.
• ☐ После восстановления — проверить ключевые документы и остатки.
• ☐ Настроить или перепроверить автоматическое резервное копирование по правилу 3-2-1.

Если у вашей компании до сих пор нет настроенного регулярного резервного копирования 1С — исправьте это до сбоя, а не после. Мы в АйТи Фреш берём серверы и базы 1С на обслуживание, включая резервное копирование и порядок действий при сбоях, — от 7 000 ₽/мес; состояние бэкапов проверяем в первый же день работы.

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