Администрирование · 11 мин
Как запустить 1С, если было прервано резервное копирование
Что делать, если 1С не запускается после прерванного резервного копирования: диагностика блокировок, восстановление базы, проверка целостности и профилактика сбоев.
Прерванное резервное копирование — одна из самых частых причин, по которой 1С отказывается запускаться или выдаёт ошибку при входе в базу. Сбой питания, разрыв сети, нехватка места на диске или принудительное завершение процесса могут оставить базу в «подвешенном» состоянии: с незакрытыми транзакциями, остаточными блокировками или частично записанными файлами.
Хорошая новость в том, что в большинстве случаев ситуация обратима. Файловые базы обычно восстанавливаются через тестирование и исправление либо перенос данных в чистую базу, а клиент-серверные — через откат на последнюю целостную копию или штатные средства СУБД. Главное — не паниковать и не выполнять поспешных действий вроде удаления файлов базы или повторного запуска копирования поверх недописанного архива.
Ниже разобраны конкретные шаги: как оценить масштаб проблемы, снять блокировки, восстановить работоспособность файловой и серверной базы, проверить целостность данных и предотвратить повторение ситуации.
Что происходит с базой при прерывании копирования
Резервное копирование в 1С выполняется двумя основными способами: выгрузкой в файл .dt через конфигуратор и копированием файла базы 1Cv8.1CD (для файлового варианта) либо средствами СУБД (для клиент-серверного). Прерывание каждого из этих процессов даёт разные последствия.
При прерванной выгрузке в .dt сама рабочая база обычно не страдает — повреждённым оказывается только файл выгрузки, который просто нельзя использовать для восстановления. Опаснее ситуация, когда копирование выполнялось средствами файловой системы или сторонним софтом и процесс был прерван на половине: файл 1Cv8.1CD мог быть захвачен частично, а антивирус или программа архивации могла оставить на нём блокировку.
В клиент-серверном варианте прерывание бэкапа средствами SQL Server или PostgreSQL обычно не повреждает рабочую базу, но может оставить недописанный файл бэкапа и зависшие сессии на стороне СУБД. Понимание того, какой именно сценарий произошёл, определяет дальнейшие действия.
Проверьте наличие файла 1Cv8.cdn в папке базы или блокировку в консоли кластера
Проверьте целостность утилитой chdbfl.exe и тестированием в конфигураторе
Запустите тестирование и исправление с проверкой логической и ссылочной целостности
Используйте предыдущую удачную копию; рабочая база при этом может быть цела
Первые действия: как не усугубить проблему
До любых восстановительных операций сделайте копию текущего состояния базы — даже если она «битая». Для файловой базы скопируйте всю папку с файлом 1Cv8.1CD в отдельное место. Это страховка: если тестирование и исправление или другие процедуры ухудшат ситуацию, у вас останется исходное состояние для повторной попытки или передачи специалисту.
Не запускайте повторное резервное копирование поверх недописанного файла и не удаляйте ничего из папки базы, кроме явно служебных файлов блокировок. Также убедитесь, что все пользователи завершили работу: восстановительные операции выполняются только в монопольном режиме.
Снятие блокировок после прерванного копирования
Самая частая причина, по которой база «не запускается» после сбоя копирования, — остаточные блокировки. При выгрузке в .dt конфигуратор устанавливает блокировку соединений, и если процесс прервался аварийно, признак блокировки мог остаться.
Файловая база
Откройте папку с базой и проверьте наличие служебных файлов. Файл 1Cv8.cdn — это признак установленной блокировки соединений: удалите его, если уверены, что копирование завершено и никто не работает. Файл 1Cv8.1CL — журнал сеансовой блокировки, он также может препятствовать запуску после аварийного завершения; его тоже можно удалить при закрытой базе.
Клиент-серверная база
Откройте консоль администрирования сервера 1С, найдите базу в списке информационных баз и проверьте свойства: снимите флажок «Блокировка регламентных заданий» и «Блокировка начала сеансов», если они остались установленными. Также проверьте список активных сеансов и завершите зависшие.
- 1Убедитесь, что все пользователи вышли из базы и процессы 1cv8.exe завершены
- 2Откройте папку с базой и найдите файлы 1Cv8.cdn и 1Cv8.1CL
- 3Удалите эти файлы (не трогайте 1Cv8.1CD и 1Cv8.1CD.cfl)
- 4Попробуйте запустить базу в режиме конфигуратора
- 5Если запуск успешен — проверьте работу в режиме предприятия
Восстановление файловой базы при повреждении
Если после снятия блокировок база не открывается или выдаёт ошибки чтения, вероятно, повреждён файл 1Cv8.1CD. Первый инструмент — утилита chdbfl.exe из каталога bin установленной платформы. Она проверяет физическую целостность файла базы. Запустите её, укажите путь к 1Cv8.1CD, включите режим «Исправлять обнаруженные ошибки» и дождитесь результата. Работает утилита только с закрытой базой.
Второй уровень — «Тестирование и исправление» в конфигураторе (меню «Администрирование»). Отметьте проверки логической и ссылочной целостности, выберите режим «Тестирование и исправление» и вариант обработки ошибок «Не изменять» для первого прохода — так вы увидите масштаб проблем без риска потерять данные. Только после оценки решайте, запускать ли исправление.
Если ни утилита, ни тестирование не помогли, остаётся перенос данных: создайте пустую базу из конфигурации поставщика или из последнего удачного .dt и загрузите туда данные. Когда доступен конфигуратор повреждённой базы, попробуйте выгрузить данные через обработку переноса или типовую выгрузку — часть информации удаётся спасти даже из сильно повреждённой базы.
C:\Program Files\1cv8\<версия платформы>\bin\chdbfl.exeВосстановление клиент-серверной базы
В клиент-серверном варианте рабочая база при прерванном бэкапе повреждается редко — СУБД защищает данные транзакционным журналом. Сначала проверьте, запущены ли службы сервера 1С и СУБД, нет ли зависших сессий и блокировок на уровне базы данных.
Если база данных всё же повреждена (например, сбой произошёл на уровне дисковой подсистемы), восстановите её из последнего целостного бэкапа средствами СУБД: для MS SQL Server — через RESTORE в Management Studio, для PostgreSQL — через pg_restore. После восстановления проверьте целостность штатными средствами СУБД (DBCC CHECKDB для MS SQL) и только затем подключайте пользователей.
Как выбрать действие
Проверка результата после восстановления
Запуск базы — ещё не признак полного восстановления. После успешного входа проверьте ключевые участки: откройте несколько документов за последние дни работы, сформируйте оборотно-сальдовую ведомость или аналогичный сводный отчёт, сверьте итоги с последними известными значениями (например, с данными из выгруженных отчётов или печатных форм).
Особое внимание уделите данным, которые записывались в момент сбоя: документы за день аварии, непроведённые операции, остатки по складу и расчётам. Найденные расхождения исправляйте вручную документами корректировки, а не прямым редактированием — так сохранится аудиторский след.
Как проверить результат
Оба режима открываются без ошибок
Ошибки чтения, зависания при открытии
Список ошибок пуст или содержит единичные замечания
Массовые ошибки ссылочной целостности
Итоги совпадают с известными значениями
Расхождения в остатках и оборотах
Открываются и проводятся штатно
Ошибки при открытии или проведении
Профилактика: как не повторить сбой
Основное правило — копирование должно быть регулярным, автоматическим и проверяемым. Настройте расписание выгрузки .dt или бэкапа средствами СУБД на нерабочие часы и периодически проверяйте, что копии реально создаются и загружаются в тестовую базу. Копия, которую никогда не проверяли, нельзя считать надёжной.
Исключите папку с базой из активной проверки антивируса, чтобы он не блокировал файлы во время копирования. Следите за свободным местом на диске: нехватка места — частая причина обрыва выгрузки. Для файловых баз избегайте размещения на сетевых дисках с нестабильным соединением, а для серверных — настройте регламентные бэкапы средствами самой СУБД, а не копированием файлов базы.
Частые вопросы
Можно ли запустить 1С, не удаляя файл 1Cv8.cdn?
Нет, пока файл блокировки существует, соединения с базой запрещены. Если вы уверены, что копирование завершено и никто не работает, файл можно удалить вручную — это стандартный способ снятия блокировки. Предварительно убедитесь, что процессы 1cv8.exe завершены.
Удалит ли chdbfl.exe мои данные?
Утилита исправляет физическую структуру файла базы и в большинстве случаев сохраняет данные. Однако при сильных повреждениях отдельные нечитаемые участки могут быть потеряны. Поэтому перед запуском всегда делайте копию файла 1Cv8.1CD.
Чем восстановление из .dt отличается от копирования файла базы?
Выгрузка в .dt сохраняет данные в платформенном формате и подходит для переноса между файловым и клиент-серверным вариантами. Копирование файла 1Cv8.1CD быстрее, но требует монопольного доступа и переносит базу «как есть», включая возможные скрытые дефекты. Для регулярных бэкапов надёжнее выгрузка .dt или бэкап средствами СУБД.
База запустилась, но часть документов пропала. Что делать?
Проверьте, не стоит ли фильтр по дате или организации в журнале документов. Если документы действительно отсутствуют, восстановите их из последней копии: загрузите копию в отдельную базу и перенесите недостающие документы обработкой переноса данных или введите вручную по первичным бумажным документам.
Как часто нужно делать резервные копии?
Ориентируйтесь на допустимый объём потери данных: для активно работающей базы разумный минимум — ежедневная копия, для баз с небольшим числом операций — несколько раз в неделю. Храните копии на отдельном носителе или в другом физическом расположении и периодически проверяйте их загружаемость.
Что важно запомнить
Прерванное копирование чаще оставляет блокировки, чем реальные повреждения. Сначала сохраните копию текущего состояния базы, затем снимите блокировки, проверьте целостность штатными средствами и только потом применяйте исправление. Регулярные проверенные копии на отдельном носителе — единственная надёжная защита от повторения ситуации.