Сколько стоит час простоя: строим стратегию восстановления данных

Почти в каждой компании, с которой мы работали — от промышленности до ритейла — план аварийного восстановления выглядит одинаково. Резервные копии создают по расписанию, метрики RTO и RPO согласованы с бизнесом. А потом случается пожар, сбой серверов или атака шифровальщика — и выясняется, что план существует только на бумаге, а быстро поднять критичные сервисы невозможно.

Эта статья — о том, как преодолеть пропасть между формальным наличием бэкапов и реальной доступностью данных.

Почему «бэкап» не равен доступности данных

Резервное копирование — это вопрос не хранения, а восстановления. Если критичные для бизнеса сервисы не поднимаются в нужный срок, то неважно, сколько копий и на каких носителях лежит. Бэкап есть, фактически бизнес не защищён. 

Поэтому проектирование системы защиты стоит начинать не с закупки терабайтов, а с расчёта двух бизнес-метрик:

RTO (Recovery Time Objective) — сколько времени есть на восстановление, прежде чем ущерб станет неприемлемым.

RPO (Recovery Point Objective) — какой объём данных бизнес готов потерять безвозвратно

Это — цели восстановления, которые переводят бизнес-цели на язык ИТ-инфраструктуры — в мегабайты в секунду, пропускную способность каналов, количество CPU и людей.

О сохранности бэкапов также стоит задуматься заранее. По статистике, 94% организаций, переживших атаку шифровальщика, сталкивались с попытками злоумышленников уничтожить резервные копии. В 57% случаев это удавалось. Логика атакующих проста: без бэкапа у жертвы нет выбора, кроме как платить выкуп.

Вот тут и появляется логичный запрос бизнеса: «Окей, сколько мы теряем и сколько стоит снизить риск?»

Сколько стоит час простоя

Разберём простой пример расчёта для среднего интернет-магазина с собственным контакт-центром.

• Выручка: 30 млн ₽/день, маржинальность — 20%
• В рабочие часы проходит 70% суточной выручки
• SLA-штрафы и возвраты при простое: ~300 тыс ₽/час
• Падение производительности из-за ручной обработки: ~200 тыс ₽/час

Итого стоимость одного часа простоя:

• Потерянная маржа: 30 млн × 0,7 / 10 рабочих часов = 2,1 млн ₽ выручки → 420 тыс ₽ маржи
• Штрафы: 300 тыс ₽
• Операционные потери: 200 тыс ₽

Итого: ~920 тыс ₽/час. И это без учёта репутационного ущерба.

После такого расчёта дискуссия на тему «стоит ли строить нормальный контур резервирования» перестаёт быть философской.

Переводим RTO в физику

Самая распространённая ошибка при проектировании системы резервного копирования — думать исключительно категорией «покупаем объём». При аварийном восстановлении критичен не столько размер хранилища, но и устойчивая производительность записи/чтения и способность уложиться в эксплуатационное окно. 

Формула, которая помогает всё расставить по местам:

Требуемая пропускная способность = Объём данных / Окно восстановления

Например: 150 ТБ критичных данных, требование восстановиться за 8 часов. «Чистая» математика даёт около 40 Гбит/с. 

Но в реальности эта цифра выше — нужно заложить накладные расходы протоколов, конкуренцию с production-трафиком, шифрование, контроль целостности, мелкие файлы, просадки производительности. Реальная цифра окажется ближе к 85 Гбит/с. 

Стандартный канал 10 Гбит/с в такой ситуации просто не работает.

Что считать кроме «гигабит»

При аудите готовности к восстановлению считаем не одну цепочку, а три:

1. Запись бэкапа: источник — прокси — репозиторий.
2. Чтение бэкапа: репозиторий — среда восстановления — сервис.
3. Сеть: между площадками и внутри ЦОДа.

Опорные стратегии резервного копирования

Одним решением всё не закрыть. Нужно строить архитектуру, где каждый уровень отвечает за свою часть.

Четыре критичных уровня архитектуры

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

Слой быстрого восстановления
Снимки томов, виртуальных машин, БД для быстрого отката. Хороши для ситуаций «случайно удалили таблицу» или «патч положил сервис». Плохо работают против шифровальщика, если снимки доступны из того же домена администрирования.

Слой резервного копирования
Полноценные резервные копии с каталогами, точками восстановления, политиками хранения, контрольными суммами и отчётами. Основной инструмент восстановления.

Классический золотой стандарт резервного копирования — правило 3‑2‑1: три копии данных, на двух разных типах носителей, одна — вне основной площадки.

Сейчас обсуждают 3‑2‑1‑1‑0: добавляется одна неизменяемая копия и требование 0 ошибок восстановления — то есть его регулярное тестирование.

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

Инструменты реализации стратегии

Платформы резервного копирования
Здесь обычно живут расписания, репозитории, политики, каталоги, оркестрация восстановления. Типичные представители — Veeam, Commvault, Rubrik, Cohesity, Veritas. 

Объектные хранилища S3
S3 (Simple Storage Service) — это облачные сервисы для хранения неограниченных объемов неструктурированных данных. Хранение масштабируется проще, а политики неизменяемости можно реализовать на уровне хранилища. 

Инфраструктурная база для геораспределения и скорости
Это то, что обычно решает судьбу восстановления: каналы, L1-L2 связность, физическое резервирование. У нас в CORTEL это выросло в масштабный инфраструктурный проект: оптическое кольцо между ключевыми ЦОДами Новосибирска с возможностью масштабирования. 

Облако под DR и тесты восстановления
Облако под аварийное восстановление — это использование удаленной облачной инфраструктуры как резервной площадки для быстрого восстановления. Если ваша задача — не просто «склад бэкапов», а поднятие сервисов на альтернативной площадке, вам нужна среда, где можно развернуть восстановленный контур.

Что выбрать под разные RTO и RPO

• Если RPO близок к нулю, а RTO — минуты, одних бэкапов недостаточно. Нужны репликации и заранее подготовленная резервная площадка восстановления.
• Если RPO — часы, а RTO — несколько часов: основной контур — резервные копии + быстрая площадка, где можно подняться или хотя бы восстановить критичные данные и интерфейсы.
• Если RPO — сутки, а RTO — день, можно жить «классическим» бэкапом, но с обязательной офлайн‑копией, иначе шифровальщик вырежет шанс восстановиться. 

Защита от шифровальщиков: три принципа

1. Разводим домены управления
Если атакующий получил доступ администратора, он не должен автоматически получить доступ к бэкап-инфраструктуре. Вас спасёт изолированный контур: отдельные учётные записи, многофакторная аутентификация и отдельные политики.

2. Неизменяемость на уровне хранилища
Если неизменяемая копия реализована только политикой в бэкап-ПО, то при компрометации бэкап-сервера теряется и политика, и данные. Надёжнее, когда неизменяемость обеспечивается нижним слоем:

• В S3-экосистеме это Object Lock — WORM-модель, при которой объект нельзя удалить или перезаписать в течение заданного срока, независимо от того, кто имеет доступ к хранилищу.
• В бэкап-репозиториях это hardened repository с режимом immutability, где файлы бэкапов заблокированы на период хранения.

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

Как не утонуть в данных

Задача ИТ-команды: найти баланс между скоростью восстановления, стоимостью дисков и отказоустойчивостью архива.

Здесь на помощь приходит классический паттерн GFS (Grandfather-Father-Son). Идея в том, чтобы использовать разные интервалы сохранения: ежедневные, еженедельные, ежемесячные и ежегодные точки. Вместо одной длинной уязвимой цепочки вы получаете несколько независимых. Это упрощает долгосрочное хранение и снижает риск потерять всю историю из-за одной проблемы.

Как считать нужную ёмкость

Чтобы понять масштаб затрат, возьмём простой пример:

• 120 ТБ production-данных
• Ежедневная изменяемость (change rate) ~3% = 3,6 ТБ/день
• RPO: сутки для большинства систем, 4 часа для критичных
• Хранение: 14 ежедневных + 8 еженедельных + 12 ежемесячных

Примерная оценка без дедупликации:

• 14 дней × 3,6 ТБ = 50,4 ТБ
• 8 недель × 120 ТБ = 960 ТБ
• 12 месяцев× 120 ТБ = 1 440 ТБ
• Плюс метаданные, рост данных, «плохие дни»

Без дедупликации и компрессии GFS из 120 ТБ превращается в хранилище на несколько петабайт. Поэтому нужно заранее решать, где нужны полные копии, а где хватает инкрементальных; что дороже защищать, а что — дешевле.

Пять шагов внедрения: как превратить стратегию в привычку

Шаг 1. Определяем, что на самом деле нужно спасти

Начинаем с инфраструктуры и потребностей бизнеса:

• Какие процессы должны работать при любой аварии?
• Какие данные — точка невозврата, а какие можно восстановить позже?
• Какие существуют скрытые зависимости (AD, DNS, ключи шифрования, лицензии, доступы к облаку)?

Заодно фиксируем «золотые образы» — шаблоны развёртывания платформ, конфигурации, IaC — и храним их оффлайн.

Шаг 2. Устанавливаем RTO и RPO по уровням критичности

Здесь бизнес принимает решение, например: «Платим за RTO = 4 часа для этих сервисов и за RTO = 24 часа для остальных».

Никогда не будет единого RTO. Делаем уровни — Tier 0/1/2/3 — под разную критичность и сразу переводим цели в инженерную плоскость: объём × окно = требуемая скорость.

Шаг 3. Проектируем архитектуру

На этом шаге нужно ответить:

• Где репозиторий?
• Где неизменяемая копия?
• Какой канал нужен?
• Где узкое горлышко: сеть, диски, CPU, прокси, лицензии, люди?

Шаг 4. Защищаем и контур восстановления как критическую систему

Три обязательных требования: офлайн-бэкапы, неизменяемость на уровне хранилища, регулярные тесты. 

Минимальный цикл:

• Еженедельно: автоматическая проверка задач, выборочное восстановление небольших объектов или ВМ.
• Ежемесячно: восстановление 1-2 критичных сервисов в тестовый контур с замером времени.
• Ежеквартально: тест сценария «А что, если…?».
• Ежегодно: полноценный DR-тест «как в бою».

Стратегия доступности данных начинается не с покупки хранилища или выбора программного обеспечения. А с честных RTO и RPO и с привычки регулярно восстанавливаться.

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

В теме много нюансов, которые не охватить в статье. Если у вас есть вопросы или вы хотите проконсультироваться по стратегии резервного копирования, заполните эту форму. Наши инженеры свяжутся с вами.