План восстановления после сбоя (DR): RTO и RPO простым языком

«У нас же есть бэкап» — самая опасная фраза в IT, потому что она звучит как ответ, а на деле это только половина ответа. Бэкап говорит, где лежит копия данных. Он не говорит, кто будет её разворачивать, на каком оборудовании, в каком порядке, сколько это займёт и сколько данных вы при этом потеряете. Эти вопросы закрывает план аварийного восстановления — Disaster Recovery, сокращённо DR.

Мы как IT-аутсорсер регулярно видим одну и ту же картину: бэкапы вроде бы делаются, но когда случается реальный сбой, выясняется, что восстановление никто никогда не проверял, ответственный в отпуске, а резервного сервера, на который всё это разворачивать, просто нет. Простой растягивается на сутки вместо запланированных двух часов. Этот материал — про то, как не оказаться в такой ситуации.

Что такое DR и зачем он нужен

DR (Disaster Recovery — аварийное восстановление) — это набор процедур, инфраструктуры и регламентов, которые возвращают IT-системы компании в рабочее состояние после серьёзного сбоя. Под сбоем здесь понимается не «завис ноутбук бухгалтера», а событие, которое выводит из строя критичный сервис или целую площадку: вышел из строя сервер с базой 1С, сгорел RAID-массив, шифровальщик зашифровал файловый сервер, в дата-центре пропало питание, затопило серверную.

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

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

RTO и RPO на пальцах

Весь DR строится вокруг двух чисел. Их нужно понять один раз и навсегда — дальше всё становится логичным.

RTO (Recovery Time Objective) — допустимое время простоя. Это ответ на вопрос «сколько максимум часов бизнес может прожить без этого сервиса, прежде чем потери станут неприемлемыми». RTO 4 часа означает: при сбое в 11 утра сервис должен снова работать к 15:00. RTO — это про скорость восстановления.

RPO (Recovery Point Objective) — допустимая потеря данных. Это ответ на вопрос «сколько последних данных бизнес готов потерять безвозвратно». RPO измеряется во времени между последней резервной точкой и моментом сбоя. RPO 1 час означает: при сбое мы откатываемся к состоянию максимум часовой давности, то есть теряем не больше часа введённых данных. RPO — это про объём потерянной работы.

Наглядно на одной шкале времени:

• Сделали бэкап в 10:00. Это последняя резервная точка.
• Сервер упал в 11:00. С 10:00 до 11:00 — час работы, который ещё не попал в бэкап.
• Если RPO = 1 час, такая потеря в норме: восстанавливаемся из копии 10:00, теряем час ввода (его придётся переделать руками по бумажным накладным или памяти).
• Восстановили и запустили систему к 15:00. От падения (11:00) до запуска (15:00) прошло 4 часа — это фактический RTO. Если целевой RTO был 4 часа, уложились.

Простая мнемоника: RTO — «как быстро поднимем», RPO — «сколько работы переделаем». Чем меньше оба числа, тем дороже инфраструктура: нулевой RPO требует непрерывной репликации данных, нулевой RTO — горячего дублирующего контура, который подхватывает нагрузку автоматически. Подробное определение обоих терминов мы держим в Вики-статье RPO и RTO.

Как определить целевые RTO и RPO по сервисам

Главная ошибка — назначать всем системам один RTO и RPO. Это либо дорого (защищаете прайс-лист так же серьёзно, как биллинг), либо опасно (защищаете биллинг так же слабо, как прайс-лист). Правильный подход — разнести сервисы по уровням критичности.

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

Цифры в таблице — типовые ориентиры, а не норматив: для конкретной компании их утверждает бизнес, а не IT. Задача IT — честно сказать, во сколько обойдётся каждый уровень, и дать выбрать. Часто оказывается, что критичных сервисов всего два-три, и серьёзные деньги нужно вкладывать только в них, а остальное закрывается обычным бэкапом по схеме 3-2-1.

Важный нюанс: RTO и RPO у одного сервиса могут сильно различаться. Для бухгалтерской базы потерять данные недопустимо (RPO близко к нулю — ставим частую репликацию), а вот подождать восстановления пару часов терпимо (RTO 2-4 часа — горячий резерв не нужен). Разделяя эти два показателя, вы не переплачиваете.

Из чего состоит DR-план

DR-план — это не одностраничная памятка «позвонить админу». Рабочий план содержит как минимум следующие компоненты.

1. Перечень сервисов и их целевые RTO/RPO. Тот самый список из предыдущего раздела, утверждённый бизнесом. Это фундамент: всё остальное проектируется под эти числа.

2. Резервные копии. Бэкапы по схеме, которая обеспечивает заявленный RPO. Если RPO 15 минут — нужна репликация или частые инкрементальные копии, суточный бэкап тут не подойдёт. Копии должны лежать минимум в двух местах, одно из которых физически отделено от основной площадки (защита от пожара, затопления, шифровальщика). Базовый стандарт — правило 3-2-1.

3. Резервный контур. Оборудование или облачная площадка, куда разворачиваются системы при сбое. Бывает трёх температур: холодный (железо/виртуалки поднимаются с нуля из бэкапа — дёшево, но RTO большой), тёплый (контур стоит наготове, данные подливаются регулярно — баланс), горячий (полный дубль работает параллельно и подхватывает нагрузку мгновенно — дорого, но RTO близок к нулю).

4. Runbook — пошаговая инструкция восстановления. Документ, в котором по каждому сценарию сбоя расписано: что проверить, в каком порядке поднимать сервисы (сначала контроллер домена, потом база, потом приложения), какие команды и доступы нужны, как убедиться, что всё заработало. Runbook пишется так, чтобы по нему смог действовать дежурный инженер в три часа ночи, а не только автор плана.

5. Ответственные и связь. Кто объявляет аварию, кто принимает решение о переключении на резерв, кто восстанавливает, кто общается с клиентами. Контакты, замены на случай отпуска, порядок эскалации. Без этого блока план превращается в «все звонят всем».

6. Тестирование. График учений и критерии «прошли / не прошли». План, который ни разу не проверяли на реальном восстановлении, — это не план, а гипотеза.

DR-план против просто бэкапа

Это главное недопонимание, из-за которого компании теряют дни простоя. Разложим по полочкам.

Вывод простой: бэкап — это необходимая часть DR-плана, но не равен ему. Можно иметь идеальные бэкапы и при этом неделю поднимать инфраструктуру, потому что разворачивать их не на чем и непонятно как. И наоборот: без надёжного бэкапа любой DR-план — это красивый документ ни о чём. Они работают только в связке. Кстати, непроверенный бэкап — частая причина того, что восстановление вообще проваливается; именно поэтому пункт «тест восстановления» в плане обязателен.

DRaaS как вариант для среднего бизнеса

Содержать собственный второй ЦОД ради аварийного восстановления для среднего бизнеса обычно невыгодно: это капитальные вложения в железо, которое 99% времени простаивает. Здесь на сцену выходит DRaaS (Disaster Recovery as a Service — аварийное восстановление как услуга).

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

DRaaS оправдан, когда:

• нужны короткие RTO и RPO для критичных систем, а второй ЦОД строить дорого;
• хочется превратить капитальные затраты на железо в предсказуемый ежемесячный платёж;
• нет своей команды, способной спроектировать и поддерживать резервный контур;
• нужна гарантированная и регулярно тестируемая процедура восстановления, а не «когда-нибудь настроим».

По стоимости ориентир для среднего бизнеса в Москве обычно укладывается в диапазон от десятков до сотен тысяч рублей в месяц — зависит от объёма данных, целевых RTO/RPO и «температуры» резервного контура (холодный дешевле, горячий дороже). Точную цифру можно назвать только после аудита и определения целевых показателей по каждому сервису.

Роль аутсорсера и NOC

DR-план полезен только тогда, когда кто-то постоянно за ним следит, а в момент аварии — действует по нему быстро и без паники. Здесь и подключается IT-аутсорсер с дежурным центром мониторинга (NOC — Network Operations Center).

На стороне аутсорсера обычно лежат три вещи. Первое — проектирование: провести аудит, определить вместе с бизнесом целевые RTO/RPO, выбрать схему резервирования и написать runbook. Второе — эксплуатация: следить, что бэкапы реально делаются и проходят проверку восстановления, что резервный контур в актуальном состоянии, что доступы и контакты не протухли. Третье — реакция: NOC видит аварию по мониторингу часто раньше, чем её замечают пользователи, объявляет инцидент и запускает восстановление по плану.

Именно круглосуточный NOC превращает RTO из теоретической цифры в реальную: если сбой случился в 3 часа ночи, а дежурная смена увидела его сразу и начала восстановление, то к началу рабочего дня сервис уже поднят. Без дежурства тот же сбой обнаружат только утром — и отсчёт RTO начнётся с опозданием на несколько часов.

FAQ

Чем DR-план отличается от обычного бэкапа?

Бэкап — это копия данных. DR-план — это документ и инфраструктура, которые отвечают на вопрос «как из этой копии за конкретное время поднять рабочую систему». Бэкап без плана восстановления отвечает только на «где данные», но не на «кто, куда, в каком порядке и за сколько часов их разворачивает». Бэкап — необходимая часть DR-плана, но не равен ему.

Что такое RTO и RPO простыми словами?

RTO (Recovery Time Objective) — сколько максимум времени бизнес готов прожить без сервиса, то есть допустимое время простоя до восстановления. RPO (Recovery Point Objective) — сколько данных бизнес готов потерять, измеряется во времени между последней резервной точкой и моментом сбоя. Грубо: RTO — «как быстро поднимем», RPO — «сколько работы придётся переделать».

Можно ли сделать RTO и RPO равными нулю?

На практике почти никогда. Нулевой RPO требует синхронной репликации в реальном времени, нулевой RTO — горячего дублирующего контура с автоматическим переключением. Это дорого и оправдано только для критичных систем (биллинг, торговый терминал, ядро банка). Для большинства бизнес-сервисов целятся в RTO от 1 до 8 часов и RPO от 15 минут до 24 часов — это разумный баланс цены и риска.

Что такое DRaaS и кому он подходит?

DRaaS (Disaster Recovery as a Service) — аварийное восстановление как услуга: провайдер держит для вас резервный контур в своём облаке, реплицирует туда ваши системы и по команде или автоматически запускает их при сбое. Подходит компаниям, которым нужны короткие RTO и RPO, но строить и содержать второй ЦОД невыгодно. Платите по подписке, а не капитальными вложениями в железо.

Как часто нужно тестировать DR-план?

Минимум раз в год полноценное учение с реальным восстановлением на резервном контуре, плюс частичные проверки восстановления отдельных систем раз в квартал. Непротестированный DR-план — это предположение, а не план: на учениях регулярно вскрываются забытые зависимости, устаревшие пароли и бэкапы, из которых ничего не разворачивается.

Сколько стоит внедрить DR-план?

Разброс большой и зависит от целевых RTO/RPO и архитектуры. Разработка самого плана и регламентов — это работа консультанта или аутсорсера. Инфраструктура добавляет основную часть бюджета: холодный резерв в облаке обходится недорого, тёплый и горячий контур дороже, синхронная репликация — самая дорогая. Ориентир по DRaaS для среднего бизнеса в Москве обычно укладывается в диапазон от десятков до сотен тысяч рублей в месяц в зависимости от объёма данных и целевых RTO/RPO. Точная цифра — только после аудита и определения целевых показателей по сервисам.

Вывод

Аварийное восстановление сводится к двум честным числам и одному документу. RTO отвечает, за сколько вы поднимете сервис, RPO — сколько данных потеряете. Эти числа задаёт бизнес по каждому сервису отдельно, а IT строит под них инфраструктуру и runbook. Бэкап — обязательная, но не единственная часть этой конструкции: без резервного контура, инструкции восстановления, ответственных и регулярных учений копия данных сама по себе бизнес не спасёт.

Кибер Авангард проектирует DR-планы под реальные RTO/RPO вашего бизнеса, держит бэкапы и резервный контур в актуальном состоянии и круглосуточно мониторит инфраструктуру из своего NOC — чтобы при сбое восстановление начиналось в первые минуты, а не утром следующего дня. Напишите нам, какие у вас критичные сервисы, — проведём аудит и предложим целевые RTO/RPO с ориентиром по стоимости.