53% опрошенных IT-специалистов признали, что уверены в полном восстановлении после атаки ransomware лишь частично, а их проверка бэкапов ограничивается редкими тестами. Для русскоязычных IT-команд это неприятно узнаваемая история: задача в отчетах закрыта, джоба зеленая, а в момент реального restore внезапно выясняется, что восстановить сервисы быстро и без потерь никто толком не может.
Об этой проблеме пишет The Register в материале от 27 августа 2026 года. Поводом стало исследование, которое Kaseya провела вместе с 1105 Media среди 200 IT-профессионалов. Вывод звучит без особой магии: сам факт копирования данных в хранилище еще не означает, что бизнес переживет инцидент. Бэкап считается по-настоящему полезным только после проверки, что из него можно вернуть рабочую нагрузку в нормальное состояние.
В исходном тексте это сравнивают с котом Шредингера: резервная копия как будто и существует, и не существует одновременно, пока вы не попытались ее восстановить. Ирония здесь не литературная, а вполне операционная. Если компания падает из-за атаки, сбоя железа или ошибки в инфраструктуре, вопрос уже не в том, успешно ли отработал nightly backup. Вопрос в другом: можно ли поднять конкретные системы, приложения и данные в том состоянии, которое было на момент до инцидента, и сколько часов или дней на это уйдет.
Цифры в исследовании Kaseya выглядят показательно. 53% участников сообщили, что уверены в способности своей организации полностью восстановиться после ransomware только «в некоторой степени», потому что тестирование резервных копий у них ограниченное. Еще часть респондентов, судя по публикации, оценивает свои шансы еще ниже. И только 15% заявили, что «очень уверены» в восстановлении без потери данных. Для рынка, где backup давно считается базовой гигиеной, это звучит не как мелкий недочет, а как системный разрыв между наличием инструмента и реальной готовностью к аварии.
Именно здесь начинается самая неприятная часть для ИТ-директора, руководителя инфраструктуры или MSP. Бэкап в статусе completed почти ничего не гарантирует сам по себе. Нужна не просто запись в консоли, а подтверждение, что данные целые, не повреждены, поднимаются в аварийной среде и позволяют вернуть в строй именно приложение, а не абстрактный набор файлов. Иначе команда живет в режиме слепой веры: раз система ничего тревожного не показала, значит, все хорошо. Практика обычно портит этот оптимизм быстро и дорого.
Почему старые методы перестали работать
Как объясняет Брент Торре, GM of cyber resilience в Kaseya, исторически полноценная верификация требовала слишком много времени и ресурсов, поэтому многие команды либо не занимались ею вообще, либо делали это нерегулярно. Отсюда знакомый компромисс: проверяем не все, не часто и по верхам, лишь бы закрыть формальное требование. Для небольших сред это еще как-то жило, но в инфраструктуре, где рядом существуют локальные системы, SaaS-сервисы, облачные инстансы и набор критичных endpoint-ов, такая схема быстро превращается в самообман.
Отдельно The Register проходится по ручной проверке через скриншоты. Логика понятна: система поднимает резервную копию в виртуальной среде, инженер смотрит на экран и пытается понять, действительно ли приложение загрузилось корректно. На бумаге звучит терпимо. На практике это означает, что дорогие специалисты тратят часы на рутинный просмотр изображений, спорят с ложными срабатываниями и пытаются отличить нормальный экран входа от поломанного состояния, которое только выглядит убедительно. Для бюджета безопасности это сомнительная инвестиция, а для SLA вообще плохая шутка.
Проблема не только в человеческой усталости. Ручная верификация дает сразу два вида ошибок: ложные отрицания, когда команда зря тратит время на несуществующую проблему, и ложные подтверждения, когда всем кажется, что резервная копия пригодна, а в критический момент оказывается наоборот. Чем больше инфраструктура, тем дороже каждая такая ошибка. Небольшая неэффективность в одиночной среде на масштабе MSP или крупной компании превращается в постоянное узкое место.
Есть и еще один фактор, который для российского корпоративного ИТ вполне знаком: регуляторика и аудит. В публикации Торре прямо говорит, что некоторые compliance-фреймворки уже требуют регулярно тестировать восстановление. Даже если конкретная норма не названа, общий тренд очевиден: проверять наличие копии уже недостаточно, нужно подтверждать способность восстановиться. Для бизнеса это меняет саму метрику зрелости. Недостаточно сказать «у нас есть backup». Придется отвечать на более неприятный вопрос: «Когда вы в последний раз восстанавливали этот сервис и сколько это заняло?»
Что рынок предлагает взамен
На этом фоне Kaseya и Datto продвигают идею AI-проверки скриншотов как новый стандарт. Схема такая: система автоматически поднимает виртуализированную резервную копию, делает снимок экрана и анализирует его с учетом контекста, а не только по жестким правилам. В материале говорится о применении визуального ИИ и OCR, которые помогают распознавать экран логина, дашборды, режимы обслуживания и другие состояния системы. Заявленная точность проверки — 99,9%, а ключевое обещание — меньше ложных срабатываний и больше уверенности в каждом бэкапе.
Понятно, что это спонсорский материал, и относиться к таким цифрам нужно без религиозного восторга. Но сама постановка задачи у рынка здравая. Если автоматизация действительно снимает с инженеров ручной просмотр и дает более качественный сигнал о пригодности копии к восстановлению, экономический смысл есть и для внутренних ИТ-команд, и для MSP. Люди перестают работать живыми датчиками состояния, а могут заниматься тем, за что их вообще нанимали: архитектурой, безопасностью, разбором инцидентов и профилактикой, а не листанием скриншотов по ночам.
Datto, принадлежащая Kaseya, встроила такую верификацию в свою платформу BCDR, чтобы не требовать отдельного сложного внедрения. Дополнительно компания делает ставку на интеграцию с RMM: это дает общий контекст по состоянию резервных копий, патчей, антивирусных сигнатур и endpoint-ов, а также позволяет запускать восстановление из единой консоли. Идея понятная и практичная: чем меньше прыжков между инструментами в момент аварии, тем выше шанс, что recovery пройдет по плану, а не по мотивам импровизации.
Для разработчиков, платформенных команд и бизнеса вывод здесь довольно приземленный. Проверка бэкапов перестает быть задачей только для backup-admin или подрядчика по инфраструктуре. Это часть общей устойчивости продукта и сервиса. Если ваш RPO и RTO существуют лишь в презентации, а не подтверждены регулярным restore-тестом, значит, в кризис вы полагаетесь на удачу. В условиях роста атак, усложнения стеков и хронической нехватки опытных людей рынок явно движется к непрерывной валидации и автоматическому исправлению проблем. Вопрос уже не в том, нужна ли проверка бэкапов, а в том, сколько компаний дождутся этого вывода только после первого по-настоящему болезненного восстановления.