Прервали резервное копирование 1С: что делать

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

Первое, что нужно сделать, — не паниковать и не запускать повторные операции вслепую. Определите, что именно было прервано: выгрузку из конфигуратора, копирование файла базы, бэкап SQL-сервера или восстановление. От этого зависит весь дальнейший план действий. Ниже разобраны основные сценарии, проверки целостности и способы получить рабочую копию заново.

Шаг 1. Определите, что именно было прервано

Последствия зависят от типа операции. Прерывание выгрузки (конфигуратор → «Администрирование» → «Выгрузить информационную базу») создаёт лишь неполный .dt-файл — рабочая база при этом не затрагивается. То же относится к штатному бэкапу MS SQL Server или PostgreSQL: незавершённый бэкап просто недействителен, база продолжает работать.

Совсем другое дело — прерывание загрузки (восстановления) из .dt или restore в SQL. Здесь целевая база остаётся в частично заполненном, неработоспособном состоянии. Третий сценарий — отключение питания или зависание сервера во время копирования: тогда нужно проверять и саму рабочую базу, особенно если она файловая.

Шаг 2. Проверьте состояние рабочей базы

Если прерывание произошло из-за внешнего сбоя (электричество, перезагрузка сервера, разрыв сети при файловой базе на сетевом диске), прежде чем делать новую копию, убедитесь, что сама база в порядке. Для файловой базы используйте утилиту chdbfl.exe из каталога установки платформы 1С — она проверяет физическую целостность файла 1Cv8.1CD. Запускайте её только на копии файла или при полном отсутствии подключений к базе.

Второй инструмент — «Тестирование и исправление» в конфигураторе (Администрирование → Тестирование и исправление). Отметьте режимы «Реиндексация таблиц», «Проверка логической целостности» и «Проверка ссылочной целостности». Для клиент-серверной базы логическая проверка делается тем же способом, а физическую целостность контролируют средствами СУБД (например, DBCC CHECKDB для MS SQL).

Шаг 3. Удалите недописанный файл копии

Неполный файл .dt или оборванный .bak нельзя использовать и нельзя оставлять «на всякий случай» рядом с рабочими копиями — рано или поздно кто-то восстановится из него и получит неработающую базу или потерянные данные за период. Признак недописанного .dt — размер заметно меньше предыдущих копий этой же базы и ошибка при тестовой загрузке.

Проверить файл .dt можно, создав пустую тестовую базу и попробовав загрузить в неё копию. Если загрузка доходит до конца без ошибок — копия целая. Для SQL-бэкапа аналогичная проверка — восстановление в тестовую базу с опцией VERIFYONLY (для MS SQL) как быстрая предварительная оценка.

Шаг 4. Устраните причину прерывания и повторите копирование

Типичные причины обрыва выгрузки: нехватка места на диске назначения, разрыв сети при копировании на сетевой ресурс, отключение сеанса пользователя, нехватка оперативной памяти на больших базах, антивирус, блокирующий запись файла. Прежде чем запускать копию заново, проверьте свободное место (нужен запас минимум в 1,5–2 размера базы), стабильность сети и исключения в антивирусе для каталога копий.

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

1. 1
   Зафиксируйте, какая операция прервалась и на каком этапе
2. 2
   Убедитесь, что рабочая база открывается и работает штатно
3. 3
   Удалите недописанный файл копии
4. 4
   Проверьте свободное место, сеть и исключения антивируса
5. 5
   Повторите копирование и дождитесь полного завершения
6. 6
   Проверьте новую копию тестовой загрузкой в отдельную базу

Шаг 5. Что делать, если прервалось восстановление

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

При прерванном restore в MS SQL база обычно остаётся в состоянии Restoring. Её можно вернуть командой RESTORE DATABASE ... WITH RECOVERY, но данные будут неполными — практичнее удалить базу и повторить восстановление из бэкапа целиком. Убедитесь, что на диске достаточно места под полный размер базы плюс журнал.

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

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

Полезно вести простой контроль: фиксировать размер файлов копий. Резкое уменьшение размера при той же базе — тревожный признак, даже если копирование завершилось «успешно».

Контрольные точки

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

Тестовая загрузка .dt

Норма

Загрузка завершается без ошибок, база открывается

Тревожный признак

Ошибка чтения файла или обрыв загрузки

Размер файла копии

Норма

Сопоставим с предыдущими копиями этой базы

Тревожный признак

Файл заметно меньше обычного

Данные в восстановленной копии

Норма

Документы и отчёты за последние дни на месте

Тревожный признак

Отсутствуют свежие документы, ошибки при открытии

Профилактика: как не остаться без копии

Одна копия в одном месте — это отсутствие копии. Настройте автоматическое резервное копирование по расписанию (план обслуживания в SQL, скрипты с pg_dump для PostgreSQL, пакетная выгрузка конфигуратора для файловых баз) и храните копии минимум в двух независимых местах: локально и на другом устройстве или в облачном хранилище.

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

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

Испортилась ли рабочая база, если прервалась выгрузка в .dt?

Нет. Выгрузка только читает данные и не изменяет рабочую базу. Исключение — если прерывание было вызвано внешним сбоем (отключение питания сервера): тогда стоит проверить саму базу, но виновата не выгрузка, а сбой.

Можно ли продолжить прерванную выгрузку с места обрыва?

Нет, механизма докачки у выгрузки конфигуратора и у бэкапов СУБД нет. Копирование всегда запускается заново, с самого начала.

Файл .dt есть, но при загрузке возникает ошибка. Что делать?

Файл недописан или повреждён. Использовать его нельзя. Возьмите предыдущую целую копию, а причину сбоя (место на диске, сеть, антивирус) устраните до следующей выгрузки.

Как копировать файловую базу 1С правильно?

Либо выгрузкой в .dt через конфигуратор с монопольным доступом, либо копированием файла 1Cv8.1CD при полном отсутствии открытых сеансов. Копировать файл, пока пользователи работают, нельзя — копия будет неконсистентной.

Чем бэкап SQL лучше выгрузки в .dt?

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

Как часто нужно делать резервные копии?

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