Как восстановить 1С после сбоя: пошаговая инструкция

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

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

Дальше разберём все рабочие сценарии: восстановление из резервной копии (файл .dt или архив SQL), исправление повреждённой файловой базы через тестирование и исправление, использование утилиты chdbfl.exe, восстановление после неудачного обновления и поиск удалённых объектов. Для каждого сценария указаны условия применения и ограничения.

Шаг 1. Диагностика: определяем тип проблемы

Прежде чем восстанавливать, нужно понять, что именно произошло. От этого зависит весь дальнейший план действий. Условно ситуации делятся на четыре группы: база не открывается вообще, база открывается, но выдаёт ошибки, потеряны отдельные данные (документы, справочники), база работает, но после обновления появились некорректные данные.

Типичные признаки повреждения файловой базы: ошибка «Файл базы данных повреждён» при запуске, внезапные вылеты платформы, ошибки вида «Ошибка СУБД» при записи документов. Если база клиент-серверная (SQL Server, PostgreSQL), симптомы другие: ошибки на стороне СУБД, недоступность сервера, битые страницы данных.

Шаг 2. Обязательная страховка перед восстановлением

Любое восстановление начинается с создания копии текущего состояния, даже если база повреждена. Для файловой базы просто скопируйте всю папку с базой (главное — файл 1Cv8.1CD) в отдельное место на диске или на внешний носитель. Для клиент-серверной базы сделайте выгрузку в .dt, если база ещё открывается, либо снимите бэкап средствами СУБД (BACKUP DATABASE в MS SQL, pg_dump для PostgreSQL).

Эта копия — ваша точка возврата. Если тестирование и исправление или chdbfl.exe ухудшит состояние базы (такое случается при сильных повреждениях), вы сможете вернуться к исходному состоянию и попробовать другой метод. Без этой копии ошибка необратима.

Шаг 3. Восстановление из резервной копии .dt (файловый вариант)

Если у вас есть выгрузка базы в формате .dt — это самый надёжный путь. Файл .dt содержит и данные, и конфигурацию, поэтому восстанавливает базу полностью. Порядок действий: откройте конфигуратор, в меню «Администрирование» выберите «Загрузить информационную базу», укажите файл .dt и дождитесь завершения. После загрузки платформа предложит перезапустить конфигуратор — согласитесь.

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

Если база клиент-серверная, .dt тоже работает: загрузка выполняется через конфигуратор так же, но для больших баз (десятки гигабайт) процесс долгий. В этом случае быстрее восстановить базу из бэкапа средствами СУБД — восстановление занимает минуты вместо часов.

1. 1
   Скопируйте текущую папку базы в резервное место
2. 2
   Откройте конфигуратор нужной базы
3. 3
   Меню «Администрирование» → «Загрузить информационную базу»
4. 4
   Укажите файл .dt и дождитесь окончания загрузки
5. 5
   Перезапустите конфигуратор по предложению платформы
6. 6
   Зайдите в режиме предприятия и проверьте ключевые отчёты и документы

Шаг 4. Тестирование и исправление повреждённой базы

Если резервной копии нет или она слишком старая, а база открывается в конфигураторе, используйте встроенный механизм «Тестирование и исправление» (меню «Администрирование» в конфигураторе). Процедура проверяет физическую и логическую целостность базы и может исправить часть ошибок автоматически.

Запускать тестирование нужно в монопольном режиме — все пользователи должны выйти из базы. Отметьте проверки: «Реиндексация таблиц», «Проверка логической целостности», «Проверка ссылочной целостности». В блоке обработки ошибок выбирайте варианты аккуратно: «Создавать объекты» восстанавливает потерянные ссылки пустышками, «Удалять объект» удаляет битые данные безвозвратно. Для первого прохода безопаснее вариант «Не изменять» — вы увидите список ошибок и сможете оценить масштаб.

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

Шаг 5. Утилита chdbfl.exe — когда конфигуратор не открывает базу

Если файловая база не открывается даже в конфигураторе с ошибкой «Файл базы данных повреждён», остаётся утилита chdbfl.exe. Она поставляется вместе с платформой и лежит в папке bin установленной версии 1С (например, C:\Program Files\1cv8\<версия>\bin\chdbfl.exe). Утилита работает напрямую с файлом 1Cv8.1CD и проверяет его физическую структуру.

Порядок работы: закройте все сеансы 1С, убедитесь, что файл базы никем не занят, запустите chdbfl.exe, укажите путь к файлу 1Cv8.1CD, поставьте флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить». После завершения попробуйте открыть базу в конфигураторе и сразу запустите тестирование и исправление для логической проверки — chdbfl чинит только физический уровень.

C:\Program Files\1cv8\8.3.22.1750\bin\chdbfl.exe

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

Шаг 6. Восстановление после неудачного обновления конфигурации

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

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

Шаг 7. Восстановление отдельных удалённых объектов

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

Практический способ: разверните резервную копию в новую пустую базу, откройте обе базы и перенесите данные обработкой «Выгрузка и загрузка данных XML» (она есть на диске ИТС и во многих типовых конфигурациях). Обработка переносит объекты с сохранением ссылок, если конфигурации баз идентичны. Для единичных документов иногда проще ввести их заново по первичным документам.

Если удаление произошло недавно и копии нет, проверьте журнал регистрации (в конфигураторе: «Администрирование» → «Журнал регистрации»): там видно, кто и когда удалил объект, а иногда — его представление, что поможет восстановить данные вручную.

Проверка результата и профилактика

После любого восстановления базу нужно проверить, прежде чем отдавать пользователям в работу. Минимальный набор проверок: база открывается в режиме предприятия без ошибок, ключевые отчёты (ОСВ, анализ счёта, складские отчёты) формируются и сходятся с ожидаемыми остатками, документы проводятся без ошибок, справочники открываются и не содержат «битых ссылок».

Чтобы восстановление больше не понадобилось в аварийном режиме, настройте регулярное резервное копирование. Для файловой базы достаточно ежедневного копирования папки базы или выгрузки .dt по расписанию через планировщик задач. Для клиент-серверной — настройте регламентные бэкапы средствами СУБД. Храните копии на другом физическом носителе или в облаке и периодически проверяйте, что копия реально разворачивается.

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