📢 Из практики: как мы восстановили базу из бэкапа, сделанного «в прошлом году»

Говорит технический директор ITENTIS GROUP, Анатолий Бовсуновский.

Хотим сегодня поделиться кейсом, важно: клиент разрешил рассказать эту историю в обезличенном виде.

Обратилась российская типография по печати на одежде, производственный цех с классическим набором ИТ: 1С для учета и продаж, несколько рабочих баз, офисный файловый сервер (клиент обслуживался у другой ИТ-компании, но потерял доверие и обратился к нам).

Что произошло? Однажды бухгалтерия и отдел продаж попытались зайти в 1С и увидели вместо привычных документов набор бессмысленных символов. Несколько баз были зашифрованы, а следом на почте обнаружили уведомление: если хотите получить ключ для расшифровки, переведите определенную сумму в криптовалюте по указанным реквизитам.

Из регулярных бэкапов у компании почти ничего не было. Что-то пытались копировать, часть копий лежала на тех же серверах и дисках, которые уже пострадали.

Фактически в живом состоянии остался один вариант - «бэкап последней надежды», который когда-то давно был выгружен и увезен из офиса. Именно он и стал точкой восстановления. Да, бэкап оказался прошлогодним, с заметным лагом по данным, но это было лучше, чем полная потеря истории.

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

Выводов из этой истории несколько.

💡Первое: шифровальщики к 2026 году становятся одной из главных угроз для компаний любого масштаба. Это, к сожалению, практическая реальность, которую мы видим в полях.

💡Второе: резервное копирование должно быть регулярным и формализованным процессом. Нужен понятный регламент: что копируем, как часто, где храним, кто отвечает и как проверяем восстановление.

💡Третье, самое важное: должен существовать бэкап, физически и логически отделенный от боевой инфраструктуры. Если все копии живут в той же системе, что и продуктив, шифровальщик или ошибка администратора с одинаковым успехом снесут и данные, и резерв.