Бэкап есть, а 1С не поднимается: почему копии врут и как это исправить

Резервное копирование · 14.08.2026 · обновлено 13.10.2026 · 13 мин чтения · Команда НПП РЕКОРД

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

Коротко. Резервная копия 1С чаще всего не поднимается по пяти причинам: файловую базу скопировали во время работы пользователей, у SQL-базы нет копий журнала транзакций, копии лежали в той же сети и их зашифровали, хорошую копию затёрла ротация или копию никто ни разу не пробовал восстановить. Лечится регламентом: правильный способ копирования для вашего типа базы, правило 3-2-1-1-0 с неизменяемой копией и ежемесячное тестовое восстановление с замером времени.

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

• 96% — атак вымогателей нацелены и на бэкапы
• 76% — таких попыток успешны (копии повреждены или зашифрованы)
• 54% — пострадавших восстановились из бэкапа (минимум за шесть лет)

Источник: Sophos State of Ransomware 2025

Почти половина компаний после атаки не смогла восстановиться из собственных копий

Семь причин, почему копия не поднимается

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

Файловая база — это один большой файл 1Cv8.1CD. Пока пользователи работают, он постоянно меняется, и простое копирование файла поверх работающей системы даёт копию, собранную из кусков разного времени. Такая копия может не открыться вообще или открыться с повреждениями, которые всплывут позже.

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

Как правильно копировать клиент-серверную базу

В клиент-серверном варианте данные хранит СУБД — MS SQL Server или PostgreSQL. Копировать нужно её средствами, а не файлами базы на диске.

• MS SQL Server. Модель восстановления Simple — только полные и разностные копии, вы теряете всё после последней копии. Модель Full позволяет восстановиться на любой момент времени, но требует регулярных копий журнала транзакций — иначе журнал растёт до заполнения диска. Делайте копии с проверкой контрольных сумм (WITH CHECKSUM).
• PostgreSQL. Логическая копия через pg_dump проста и надёжна, но для больших баз медленная. Для восстановления на момент времени используют физическую копию (pg_basebackup) плюс архивирование журналов WAL.
• Выгрузка .dt для больших SQL-баз — дополнительная, а не основная копия: она долгая и требует завершения работы пользователей, зато не зависит от версии СУБД.

Важно. Команда проверки копии (например, RESTORE VERIFYONLY в MS SQL) подтверждает, что файл копии читается, но не гарантирует, что база из него поднимется и будет целой. Надёжная проверка одна — реальное восстановление на отдельный сервер и проверка целостности восстановленной базы.

Что хранить кроме самой базы

Правило 3-2-1-1-0

Классическое правило 3-2-1 — три копии данных, на двух разных носителях, одна вне офиса — придумали задолго до шифровальщиков. Сегодня к нему добавляют ещё две цифры.

• 3 копии: рабочие данные и две резервные.
• 2 разных носителя: например, хранилище в офисе и облако.
• 1 копия вне площадки: другое здание или облачное хранилище.
• 1 неизменяемая или офлайн-копия: её нельзя удалить или перезаписать до истечения срока, даже с правами администратора.
• 0 ошибок при проверочном восстановлении: копия считается рабочей, только если из неё реально восстановились.

Неизменяемая копия вне сети — то, до чего шифровальщик не дотянется

Как за вечер проверить, что бэкап живой

1. Возьмите самую свежую копию базы 1С.
2. Разверните её на отдельном компьютере или сервере, не подключённом к рабочей базе. Никогда не восстанавливайте поверх рабочей базы.
3. Засеките время от «у нас есть файл» до «1С открылась и работает». Это ваш реальный RTO — время простоя в день аварии.
4. Откройте базу и найдите документы за вчерашний день. Дата последнего документа — ваш реальный RPO: столько работы вы потеряете.
5. Сформируйте пару ключевых отчётов, например оборотно-сальдовую ведомость, и сравните с рабочей базой.
6. Для SQL-базы проверьте целостность восстановленной базы средствами СУБД.
7. Запишите результат и время. Если восстановление заняло 6 часов, в день аварии бизнес будет стоять минимум 6 часов.

Совет. Если результат не устраивает — копия восстанавливалась слишком долго или в ней не хватило данных, — это ценная находка. Лучше узнать об этом в спокойный вечер, чем в день, когда стоит вся компания.

Регламент, который работает

Бэкап, который никто не восстанавливал, — это не бэкап, а надежда. Настоящая гарантия — копия вне досягаемости шифровальщика и записанное время, за которое вы из неё поднялись.

Теги: бэкап, 1С, восстановление, 3-2-1, MS SQL, PostgreSQL, резервное копирование