Администрирование · 10 мин
Прервано резервное копирование 1С 8: как запустить программу
Что делать, если резервное копирование 1С 8 прервалось и программа не запускается: проверка блокировок, восстановление базы, тестирование и исправление.
Резервное копирование в 1С 8 зависло или прервалось ошибкой, после чего программа отказывается запускаться — типичный сценарий, при котором сама информационная база чаще всего остаётся целой. Прерывание затрагивает в первую очередь создаваемый файл выгрузки (.dt или архив), а вот запуску мешают остаточные блокировки, зависшие сеансы в кластере или повреждённые служебные файлы вроде 1Cv8.1CD.lck, оставшиеся в папке базы. Поэтому первым шагом стоит проверить список активных сеансов в консоли кластера или диспетчере задач (процессы rphost и 1cv8) и убедиться, что в каталоге базы не осталось файлов с расширением .lck — именно они чаще всего блокируют вход после неудачного копирования.
Причины обрыва копирования обычно такие: отключение электричества, перезагрузка компьютера или сервера, разрыв сети при копировании на сетевой диск, нехватка места на диске, принудительное завершение процесса пользователем. Каждая из этих причин оставляет характерные следы, и от них зависит порядок восстановления.
Важно понимать разницу между двумя сценариями: копирование средствами 1С (выгрузка в .dt через конфигуратор) и копирование файла базы (1Cv8.1CD) средствами операционной системы. В первом случае риск для рабочей базы минимален. Во втором — если файл копировался во время работы пользователей, повреждённым может оказаться именно файл копии, а рабочая база, как правило, цела.
Шаг 1. Завершите зависшие процессы и сеансы 1С
Самая частая причина, по которой программа не запускается после прерванного копирования, — зависший процесс. При обрыве копирования сеанс 1С может остаться «висеть» в памяти, удерживая блокировку базы. Новый запуск при этом либо выдаёт ошибку «информационная база заблокирована», либо просто не стартует.
Откройте диспетчер задач (Ctrl+Shift+Esc), найдите все процессы 1cv8.exe, 1cv8c.exe и завершите их. Если база работает в клиент-серверном варианте, проверьте также процесс rphost на сервере — но завершать его следует только через консоль администрирования кластера, удалив зависшие сеансы, а не через диспетчер задач, чтобы не оборвать работу других баз.
После завершения процессов подождите 1–2 минуты: сервер 1С и СУБД могут снимать блокировки с задержкой. Затем попробуйте запустить программу обычным способом. В значительной части случаев на этом всё и заканчивается.
- 1Завершите все процессы 1cv8.exe и 1cv8c.exe в диспетчере задач
- 2Проверьте и удалите файл блокировки 1Cv8.1CL в каталоге файловой базы
- 3Попробуйте запустить 1С в обычном режиме
- 4Если не запускается — запустите конфигуратор и выполните тестирование и исправление
- 5Проверьте целостность данных и настройте копирование заново
Шаг 2. Удалите файл блокировки файловой базы
Если база файловая (лежит в папке на диске или сетевом ресурсе), проверьте её каталог. В нём должен находиться основной файл 1Cv8.1CD и, возможно, служебный файл 1Cv8.1CL — это файл блокировок. При аварийном завершении он может остаться на диске и мешать запуску, сообщая системе, что база занята.
Убедитесь, что никто из пользователей не работает с базой, и удалите файл 1Cv8.1CL. Сам файл 1Cv8.1CD трогать нельзя — это и есть ваша база данных. После удаления блокировки запустите программу снова.
Шаг 3. Оцените, не повреждена ли сама база
Если блокировки сняты, а программа всё равно не запускается — падает с ошибкой, зависает на заставке или выдаёт сообщение «ошибка формата потока», «файл базы данных повреждён», — нужно проверить целостность базы. Такое бывает, если обрыв произошёл в момент, когда 1С одновременно записывала данные (например, копирование запускалось без монопольного режима, и пользователи продолжали работать).
Признаки повреждения файловой базы: ошибки при открытии, сообщения о невозможности прочитать страницы данных, пропавшие документы или справочники после запуска. Для клиент-серверной базы характерны ошибки СУБД в журнале и отказ при обращении к конкретным таблицам.
Диспетчер задач и каталог базы
Очистка кэша, тестирование и исправление
Путь к базе в списке, журнал регистрации
Размер файла копии, повторная выгрузка
Шаг 4. Запустите тестирование и исправление
Штатный инструмент восстановления файловой базы — «Тестирование и исправление» в конфигураторе. Откройте базу в режиме конфигуратора, перейдите в меню «Администрирование» → «Тестирование и исправление». Отметьте пункты «Реиндексация таблиц», «Проверка логической целостности» и «Проверка ссылочной целостности», выберите вариант «Тестирование и исправление» и запустите процесс.
На больших базах процедура может занять от десятков минут до нескольких часов — прерывать её нельзя, это как раз тот случай, когда обрыв опасен. Обеспечьте стабильное питание и достаточно свободного места на диске (временные файлы могут потребовать объём, сопоставимый с размером базы).
Если конфигуратор тоже не открывает базу, используйте утилиту chdbfl.exe из каталога установки платформы (папка bin). Укажите путь к файлу 1Cv8.1CD, включите опцию «Исправлять обнаруженные ошибки» и запустите проверку. Утилита работает на более низком уровне и часто справляется там, где конфигуратор бессилен.
C:\Program Files\1cv8\<версия платформы>\bin\chdbfl.exeШаг 5. Если база не восстанавливается — вернитесь к последней рабочей копии
Если тестирование и исправление не помогло, остаётся восстановление из резервной копии. Здесь важный момент: копия, создание которой было прервано, использовать нельзя — она недозаписана и, скорее всего, не загрузится. Нужна предыдущая, завершённая копия.
Для файловой базы восстановление — это замена файла 1Cv8.1CD на файл из архивной копии либо загрузка .dt через конфигуратор («Администрирование» → «Загрузить информационную базу»). Для клиент-серверной — восстановление средствами СУБД или загрузка .dt. После восстановления оцените потери: данные, введённые между датой копии и моментом сбоя, придётся вносить заново.
Как выбрать действие
Частые ошибки при восстановлении
Первая типичная ошибка — попытка восстановить базу из недозаписанной копии, создание которой как раз прервалось. Такой файл .dt почти гарантированно не загрузится или загрузится частично, что ещё хуже: вы получите базу с неполными данными и не сразу это заметите.
Вторая ошибка — действия без предварительной копии. Перед тестированием и исправлением, перед работой chdbfl.exe, перед любой заменой файлов скопируйте всю папку базы в безопасное место. Исправляющие инструменты изменяют файл необратимо, и если что-то пойдёт не так, откатиться будет невозможно.
Третья ошибка — запуск копирования файла базы средствами ОС в рабочее время без остановки сеансов. Файл копируется подольше, чем кажется, а пользователи в это время пишут данные — в итоге копия оказывается несогласованной. Для файловых баз корректный способ — выгрузка .dt из конфигуратора или копирование файла только когда все сеансы завершены.
Как предотвратить повторение ситуации
Настройте регулярное резервное копирование с проверкой результата. Для файловых баз подойдёт выгрузка .dt по расписанию через пакетный запуск конфигуратора или скрипт, копирующий файл базы в нерабочие часы. Для клиент-серверных — штатные средства СУБД (регламентные задания обслуживания в MS SQL Server, pg_dump для PostgreSQL).
Обязательные правила: копия считается существующей только после проверки, что файл открывается и загружается; храните копии на другом физическом носителе, а не на том же диске; следите за свободным местом — нехватка места одна из главных причин обрыва копирования; исключите отключение питания во время регламентных операций, желательно использовать ИБП.
Что важно запомнить
Прерванное копирование обычно портит копию, а не рабочую базу. Порядок действий: завершить процессы, удалить файл блокировки, запустить программу; при ошибках повреждения — тестирование и исправление или chdbfl.exe; в крайнем случае — восстановление из последней завершённой копии. Перед любыми исправляющими действиями делайте копию папки базы.
Частые вопросы
Можно ли использовать файл копии, создание которого прервалось?
Нет. Недозаписанный файл .dt или частично скопированный 1Cv8.1CD содержит неполные данные. Загрузка такого файла либо завершится ошибкой, либо даст базу с потерянными записями. Используйте предыдущую завершённую копию.
База запустилась, но часть документов пропала. Что делать?
Это признак повреждения данных. Закройте базу, сделайте копию папки и выполните тестирование и исправление с проверкой ссылочной целостности. Если документы не восстановятся, сверьтесь с последней резервной копией и внесите недостающие данные вручную.
Чем отличается выгрузка .dt от копирования файла базы?
Выгрузка .dt — штатный механизм 1С, который корректно читает данные и подходит для переноса между файловым и клиент-серверным вариантами. Копирование файла 1Cv8.1CD быстрее, но требует полного отсутствия активных сеансов, иначе копия будет несогласованной.
Тестирование и исправление удалит мои данные?
Инструмент не удаляет осмысленные данные, но при проверке ссылочной целостности может очистить «битые» ссылки или удалить объекты с нечитаемыми записями. Поэтому перед запуском обязательно делается копия базы — это позволит сравнить состояние до и после.
Как понять, что копирование завершилось успешно?
Проверьте, что процесс завершился без ошибок, файл копии имеет ожидаемый размер (сопоставимый с предыдущими копиями) и открывается — для .dt это тестовая загрузка в пустую базу, для файловой копии — запуск 1С с указанием скопированной папки.
Нужно ли останавливать работу пользователей во время копирования?
Для выгрузки .dt монопольный режим не обязателен, но желательно минимизировать активность, чтобы копия была согласованной на момент времени. Для копирования файла базы средствами ОС все сеансы должны быть завершены обязательно.