Почему бэкап есть, а восстановиться не получится: разбор точек отказа

В 2025 году 89% кибератак целились не в продакшен, а в резервные копии. При этом регулярно тестируют восстановление только 8% компаний. Получается, что бэкап у всех есть, а уверенность, что из него получится подняться, мало кто проверял.

Что показывает статистика

Компания Linx вместе с сообществом Global CIO в конце прошлого года опросила руководителей, которые отвечают за развитие IT-инфраструктуры, из компаний в 27 городах России и СНГ. В выборке 15 отраслей, больше всего – производство, банки и торговля. Картина такая.

С потерей выручки из-за простоев сталкивались все опрошенные компании без исключения. 69% ловят перебои еженедельно, 14% – ежедневно. То есть речь не о случайных форс-мажорах, а о регулярном фоне, который может случиться в любой момент. При этом устойчивой к сбоям свою инфраструктуру считает только каждая пятая компания.

Формальный план аварийного восстановления есть у многих, но два респондента из пяти признались, что не проводят реальных тестов вообще, и только один из пяти сочетает документированную DR-стратегию с регулярными проверками. Идеальная частота тестирования – раз в квартал, так делают 8% опрошенных. Половина ограничивается тестом раз в полгода или в год.

Дальше самое показательное. Когда авторы исследования сопоставили ответы, выяснилось: у половины компаний, которые не тестируют восстановление, оно и не сработало, когда понадобилось. Всего по выборке 19% не уложились в заданные временные рамки, ещё 15% потеряли данные, некоторые так и не восстановились полностью.

Восстанавливаться приходится чаще: только 15% компаний ни разу не поднимались из бэкапа. Основные причины банальные – ошибки сотрудников и сбои оборудования. Атаки шифровальщиков только на третьем месте, но у них своя специфика: злоумышленники уже поняли, что бить надо по резервным копиям, поэтому большинство атак направлено именно на их шифрование или уничтожение. Защищённые от изменений хранилища при этом используют 32% компаний.

Чем дольше простой, тем хуже прогноз. 93% компаний, которые теряют данные больше чем на 10 дней, в течение года подают на банкротство.

Бэкап и DR решают разные задачи

Термины часто смешивают, поэтому договоримся о понятиях.

Бэкап отвечает на вопрос «есть ли у нас копия данных» – это процесс создания копий продуктивных данных на отдельном носителе: если рабочие данные повреждены или уничтожены, из копии можно восстановиться. Копии обычно держат на локальной площадке для оперативного восстановления и дополнительно выносят на удалённую, чтобы пережить сбой площадки целиком.

DR, он же disaster recovery, отвечает «как быстро поднимутся наши системы, если площадка выйдет из строя» – данные постоянно реплицируются на резервную площадку, и там по сути живёт копия критически важных информационных систем. Если основная площадка надолго отключилась или утрачена совсем, нагрузка переезжает на резервную.

Оба процесса оперируют двумя метриками:

• RPO –  сколько данных бизнес готов потерять без критичных последствий. 
• RTO – за какое время системы должны вернуться в нормальный режим.

Общее правило простое: чем меньше эти показатели, тем дороже их обеспечивать, причём дорожают и технические средства, и организация процессов.

DR окупается, когда RTO измеряется десятками минут, а терять данные больше чем за одну-две минуты нельзя. Бэкапов достаточно, когда защищать нужно сами данные, а не работающие системы: вернуться на несколько точек назад, пережить шифровальщика, восстановить всё в консистентном состоянии. На практике подходы комбинируют: mission critical системы закрывают через DR, остальное восстанавливают из бэкапов помедленнее.

Всё это описывается в DRP, плане аварийного восстановления. Это формализованный документ, где прописаны не только технические меры, но и организационные: кто принимает решение о переключении на резервную площадку, кто какие действия выполняет, как часто план тестируется и обновляется.

Пять мест, где ломается восстановление

Если вы думаете, что раз бэкап есть, с восстановлением всё хорошо, то на деле бэкап подтверждает только наличие копии. А восстановление – это цепочка, где кроме копии есть порядок запуска, зависимости между компонентами, авторизации, интеграции и люди, которым нужно время. Проверять надо всю цепочку, и вот пять проверок, которые помогают найти разрыв заранее.

1. Переживут ли копии тот же инцидент. Мы уже касались этого на уровне одного сервера, но правило масштабируется. Если все копии лежат в одном ДЦ, в одном облаке или под одним контуром администрирования, полноценной устойчивости нет. Важно оценить независимость резервной площадки и убедиться, что там будут связь и ресурсы для восстановления.
2. Сверены ли RTO и RPO с реальностью. Часто эти показатели живут в документах как красивые цели, которые никто не измерял на практике. Если в DRP записан час, а фактическое восстановление занимает восемь, об этом надо узнать до аварии. Полезно ещё разделять системы по классам критичности, потому что восстанавливать всё одинаково быстро затратно и не всегда обоснованно.
3. Описан ли порядок восстановления. Поднять виртуальные машины и поднять работающий сервис не одно и то же. Сервису нужна база данных, рабочая сеть, доступы, внешние интеграции. Если в момент аварии команда выясняет порядок запуска в телеграм-чате, DR-план фактически не работает. Для этого существует runbook: документ с последовательностью действий, ролями и критериями, по которым конкретный человек подтверждает, что сервис восстановлен.
4. Продуман ли failover. Заранее нужны ответы на вопросы: кто принимает решение о переключении, хватит ли ресурсов на резервной площадке, чтобы принять нагрузку, готова ли сетевая часть с балансировщиками. И отдельный пункт, про который вспоминают не все, – план возврата.
5. Регулярный dry run. DR-план устаревает по умолчанию: появилась новая система, поменялись маршруты, прошла миграция, сменился провайдер, выкатили релиз с новыми зависимостями. Тестовый прогон нужен, чтобы находить расхождения между документом и реальной инфраструктурой. Причём сам по себе прогон ничего не решает: по его итогам в план вносят изменения и сразу назначают дату следующей проверки.

Почему DR не спасает от шифровальщика

У DR есть слабое место, о котором стоит помнить отдельно. Репликация не разбирает, что она переносит: она добросовестно доставляет на резервную площадку и здоровые данные, и зашифрованные.

Сценарий выглядит так. Шифровальщик отработал на основной площадке, данные повреждены. Команда решает, что площадка потеряна, и запускает аварийное восстановление. Виртуальные машины на резервной стороне поднимаются в нужном порядке, всё по плану. А потом выясняется, что данные там те же самые: реплика успела уехать уже после шифрования. Формально DR сработал, бизнесу это не помогло.

Точки восстановления у DR-решений есть, но их заметно меньше, чем у бэкапов. Откатиться далеко в прошлое и получить консистентное состояние исторических данных – задача именно резервного копирования. Поэтому от шифровальщиков DR защищает так себе: может повезти с точкой, а может и нет. Всё упирается в то, от каких рисков вы страхуетесь.

Как строить хранение копий

Базовая схема известна давно и называется правилом 3-2-1: держать данные минимум в трёх экземплярах – продуктивные плюс две резервные копии. Носители должны быть двух разных типов, чтобы не словить на обеих копиях один и тот же баг прошивки или заводской брак. И хотя бы одна копия должна лежать на удалённой площадке, на случай если с основной что-то случится целиком.

У правила есть развитие: 3-2-1-1-0. Дополнительная единица означает, что минимум одна копия хранится в неизменяемом виде, а ноль – что восстановление регулярно тестируется. Второе спасает от бэкапа Шрёдингера: копия вроде есть, но из неё ни разу не пробовали восстановиться, поэтому неизвестно, есть ли там вообще пригодные данные. Тестировать можно руками, встроенными средствами системы резервного копирования или отдельными скриптами.

Неизменяемое хранилище устроено одним из двух способов.

1. Первый – отчуждаемые носители: записали на ленту или внешний диск, вытащили, убрали в несгораемый шкаф. Защита получается надёжная, но скорость записи и восстановления низкая, а трудозатраты мешают главному – регулярному тестированию.
2. Второй способ – ограничение на уровне прав доступа: данные можно записать один раз и читать сколько угодно, а перезаписать нельзя. Так работает, например, функция Object Lock в S3-совместимых объектных хранилищах: она защищает объекты от случайного и преднамеренного изменения или удаления. Важно понимать границы: объектное хранилище – не система резервного копирования, а удалённый репозиторий, куда система складывает копии.

Отдельный выбор – как система резервного копирования будет добираться до данных. Агентская схема ставит небольшую программу на каждый сервер и рабочую станцию: агент сидит рядом с данными и даёт гибко управлять копированием и восстановлением, но нагружает CPU и память машины, а парком агентов надо управлять. Безагентская схема работает на уровне гипервизора или отдельным сервером: разворачивается быстро, покрывает много сервисов разом, вся нагрузка остаётся на внешнем сервере. Для маленькой инсталляции обычно удобнее агенты, для большой – безагентский вариант.

Удалённой площадкой для копий может быть облако – это способ закрыть вопрос без закупки железа и строительства собственной резервной площадки, к тому же облачные провайдеры обычно строят сервисы с оглядкой на требования регуляторов. Один нюанс: восстановление из облака идёт по сети, и на небольших каналах это долго. Поэтому оперативные копии лучше держать поближе к продуктиву, а облачный репозиторий использовать как резерв резерва.

Собрать такую схему можно на инфраструктуре Linx: у компании есть объектное хранилище с Object Lock, где данные можно защитить так, что их не изменит даже администратор облака, сервис резервного копирования с локальными и удалёнными репозиториями и услуга аварийного восстановления для инфраструктур на VMware. Если у вас Hyper-V, bare metal или другая платформа виртуализации, тот же сценарий закрывается связкой с платформой Hystex, которая переносит нагрузки между разными платформами. Подробности – на linx.ru.

Итого

Готовность к аварии проверяется не наличием бэкапа, а измеренным восстановлением. Отсюда план действий:

• Сначала аудит: посчитать, во сколько обходится час простоя и потеря данных, и разбить системы на классы критичности.
• Затем вместе с бизнесом зафиксировать целевые RPO и RTO для каждого класса, спроектировать под них архитектуру и провести тестовое восстановление.
• Полученные цифры сверить с целевыми: если в план заложен час, а по факту выходит восемь, либо меняйте архитектуру, либо честно пересматривайте цели вместе с бюджетом.
• Дальше цикл: обновили план, назначили дату следующего теста.

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

Непроверенный бэкап – не страховка, а гипотеза о страховке. Разница между ними выясняется в худший момент из возможных, и стоит она, если верить статистике, до 93% вероятности банкротства при затяжной потере данных. Тестовое восстановление обходится дешевле.