Непрерывность и восстановление: RPO, RTO и как не потерять всё

Проект ЦИТадель

Большая часть раздела «Инфраструктура» посвящена системам, которые работают. Эта статья — о том, как продолжить критичные процессы и восстановить ИТ после серьёзного нарушения: потери ЦОДа или облачного региона, атаки программы-вымогателя, ошибочного удаления данных. Непрерывность бизнеса (business continuity, BC) отвечает на вопрос, как организация сохраняет приемлемый уровень работы во время инцидента; аварийное восстановление (disaster recovery, DR) — как вернуть её ИТ-системы и данные. Распространённая ошибка — считать наличие резервных копий достаточным. Центральный тезис статьи: ценность резервной копии подтверждается восстановлением, а выполнимость плана — учениями. Рассмотрим принципы, не зависящие от конкретного продукта.

1. Два числа, с которых всё начинается: RPO и RTO

До выбора технологий проводят анализ влияния на бизнес (business impact analysis, BIA): определяют критичные процессы, их зависимости и ущерб от перерыва разной длительности. Из этого анализа выводят цели восстановления:

• RPO (recovery point objective) — допустимый возраст точки, до которой должны восстановиться данные. Если инцидент произошёл в 15:00, а последняя пригодная точка относится к 14:45, окно потери составляет 15 минут. RPO влияет на частоту копирования, передачу журналов и выбор синхронной или асинхронной репликации. Нулевой RPO для подтверждённых операций при заданном сценарии отказа требует, чтобы подтверждение переживало этот отказ, — обычно за счёт синхронной записи в независимый домен. Это увеличивает задержку и всё равно не заменяет исторических копий, защищающих от логической порчи.
• RTO (recovery time objective) — целевой срок возврата бизнес-сервиса к заранее определённому уровню работы. В него входят обнаружение и объявление аварии, развёртывание инфраструктуры, восстановление и проверка данных, переключение трафика. Запуск виртуальной машины — только часть RTO. При цели в сутки может подойти восстановление из копии; цель в минуты обычно требует заранее подготовленного резерва, автоматизации и отрепетированного переключения.

RPO и RTO — цели, а не результаты измерения и не свойства продукта сами по себе. Их устанавливают владельцы бизнес-процессов вместе с ИТ, безопасностью и теми, кто отвечает за договорные и регуляторные обязательства. RTO относится прежде всего к сервису или процессу, RPO — к его наборам данных. Платежи могут требовать RPO, близкого к нулю; аналитические данные иногда допустимо пересчитать за сутки; для восстанавливаемого кэша RPO неприменим. Начальный документ DR — таблица «процесс и сервис → данные → влияние простоя → RPO → RTO → владелец». Одинаково строгие цели для всех компонентов приводят к лишним расходам, одинаково мягкие — к неприемлемым потерям.

2. Резервные копии: правило 3-2-1 и его границы

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

Распространённое расширение 3-2-1-1-0 добавляет ещё 1 офлайн- или неизменяемую копию и требует 0 обнаруженных ошибок по результатам проверки. Офлайн-копия физически или логически недоступна рабочей среде; неизменяемая копия защищена от перезаписи на срок хранения. Это разные механизмы. Их дополняют отдельный контур управления, минимальные права на удаление и независимое хранение ключей шифрования. Ноль ошибок означает успешные проверки целостности и восстановления, а не обещание, что любой будущий сценарий уже покрыт.

Типичные причины бесполезных копий: (1) рабочая система и бэкапы находятся в одном домене отказа или доверия, поэтому одна авария либо компрометация уничтожает оба; (2) копируются данные, но не конфигурация, инфраструктурный код, версии программ, сертификаты и ключи, необходимые для запуска; (3) срок хранения, скорость извлечения и пропускная способность восстановления не сверены с RPO/RTO. Перенос старых копий в холодное и архивное хранение снижает стоимость, но может увеличить время восстановления — это нужно измерить, а не предполагать.

3. Восстановление и репликация — разные вещи

Репликация — не резервное копирование. Она поддерживает несколько актуальных экземпляров состояния и потому переносит на них не только правильные, но и ошибочные изменения: удаление таблицы, порчу приложением, шифрование данных. Защита зависит от размещения реплик и режима записи:

• репликация сокращает простой при отказе тех узлов, зон или площадок, между которыми действительно размещены копии. При асинхронной репликации достижимость RPO зависит от наибольшего отставания, в том числе во время сбоя; синхронная уменьшает окно потери подтверждённых записей ценой задержки и доступности. Достижение RTO требует также обнаружить аварию, выбрать новую основную реплику и переключить клиентов;
• резервная копия сохраняет историческую точку, к которой можно вернуться после логической порчи или атаки. Доступная точка восстановления зависит не только от полного бэкапа, но и от инкрементальных копий и журналов; фактическое время восстановления — от объёма, скорости извлечения, процедуры сборки и проверки;
• снимок быстро фиксирует состояние хранилища, но может быть лишь crash-consistent, если приложение не подготовлено к снимку. Снимок в том же административном контуре и домене отказа не заменяет независимой копии; вынесенный в другую площадку или учётную запись, защищённый сроком хранения и проверенный восстановлением, он может стать частью стратегии бэкапа.

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

4. Классы DR-архитектур: цена против скорости

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

• Резервная копия и восстановление (backup and restore): заранее хранятся данные, образы и описания инфраструктуры, а вычислительные ресурсы создаются после аварии. Постоянные расходы невелики, но восстановление и проверка занимают время.
• Минимально работающий резерв (pilot light): в другой площадке постоянно работает критичное ядро, прежде всего приём реплицируемых данных; остальная инфраструктура описана кодом и разворачивается при переключении.
• Тёплый резерв (warm standby): уменьшенная, но функционально полная копия системы работает постоянно. При аварии её масштабируют до требуемой мощности и направляют на неё трафик.
• Несколько активных площадок (multi-site active-active): две или более площадки постоянно обслуживают запросы и должны иметь запас мощности на потерю одной из них. Эта стратегия даёт низкий RTO, но усложняет маршрутизацию, данные и эксплуатацию. RPO определяется моделью состояния: синхронная запись увеличивает задержку и может снижать доступность при разделении сети, асинхронная оставляет окно потери или конфликтов.

Для каждой стратегии нужно учесть не только данные и серверы, но и DNS, идентификацию, сертификаты и секреты, сетевые квоты, доступность управляющей плоскости, внешние зависимости и ёмкость резерва. Нужен также обратный путь — безопасное возвращение на основную площадку (failback), иначе первое переключение создаст новый постоянный режим без плана. Стратегию сопоставляют с таблицей RPO/RTO, а достижимые числа получают на учениях: диаграмма поставщика или название класса измерения не заменяют.

5. Репетиции: без них цели нельзя проверить

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

1. Проверка и пробное восстановление копии. Автоматическая проверка формата, контрольных сумм и журналов нужна постоянно, но периодически данные следует восстановить в изолированную среду и проверить на уровне приложения.
2. Настольные учения (tabletop exercise). Участники проходят сценарий по ролям и проверяют критерии объявления аварии, каналы связи, полномочия и последовательность действий, не отключая систему.
3. Учебное переключение и возвращение (failover/failback drill). Трафик планово переводят на резервную площадку, проверяют сервис и возвращают обратно; измеряют окно потери данных и время до прохождения приёмочных проверок, затем сравнивают их с RPO и RTO.
4. Контролируемые эксперименты с отказами. Хаос-инженерия из главы 11 курса о распределённых системах проверяет заранее сформулированную гипотезу при ограниченном радиусе воздействия, наблюдаемости и условиях немедленной остановки. Это не внезапное отключение продакшена и не замена полному восстановлению из копии.

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

6. От DR к непрерывности бизнеса

Техническое восстановление — часть непрерывности бизнеса. Организация должна поддерживать критичные услуги во время нарушения, а не только вернуть серверы. Плану нужны три слоя:

• Решения, роли и связь. Кто и по каким признакам объявляет аварию, кто разрешает переключение, кто отвечает за технику, безопасность, клиентов и регуляторов? Команда должна иметь внешний канал связи и доступную вне основной системы копию контактов и плана.
• Зависимости и порядок восстановления. База данных, идентификация, DNS, платёжный шлюз и внешние API образуют граф. Приоритет бизнес-сервиса бесполезен, если не восстановлены его критичные зависимости; для сторонних поставщиков нужны контакты, договорные обязательства и запасной порядок работы.
• Люди и допустимая деградация. Для критичных операций определяют минимальный уровень сервиса, ручной или ограниченный режим и способ последующей сверки накопленных операций. Такой обходной процесс тоже нужно проверять и ограничивать по времени.

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

7. Практикум: восстановление, которого вы не делали

Главное действие практикума — выполнить восстановление, а не только описать его.

1. Цели и подтверждённые возможности. Для знакомого рабочего или учебного сервиса составьте таблицу: бизнес-процесс, набор данных, владелец, последствия простоя через час, четыре часа и сутки, целевые RPO/RTO, зависимости. Рядом укажите последние измеренные окно потери и время восстановления со ссылкой на отчёт об учениях; если измерения не было, напишите «неизвестно». Разницу между целью и подтверждённой возможностью превратите в список задач с владельцами и сроками.
2. Восстановление в чистой среде. Выберите безопасную резервную копию и условный момент аварии T0. Не изменяя источник и рабочую систему, восстановите сервис на изолированной чистой машине или в контейнерах. Засеките время от объявления аварии до момента, когда сервис проходит заранее записанные приёмочные проверки. Проверьте структуру, количество контрольных записей или контрольные суммы и найдите время последней восстановленной подтверждённой операции: разница между ним и T0 даст фактическое окно потери. Отдельно запишите, каких конфигураций, версий программ, тестовых секретов, ключей или зависимостей не хватило. Время загрузки файла не выдавайте за RTO всего сервиса.
3. Настольные учения. Сценарий: «основной регион или ЦОД недоступен, срок неизвестен; корпоративная почта и основной поставщик идентификации тоже не работают». Пройдите критерии объявления аварии, полномочия, внешний канал связи, граф зависимостей, порядок восстановления, уведомления и последующее возвращение. Каждый вопрос без ответа занесите в протокол вместе с ответственным и сроком решения.
4. Неизменяемая или офлайн-копия. Проводите опыт только в одноразовом хранилище с неценными данными и коротким сроком: режим неизменяемости может быть необратим. Настройте Object Lock по документации выбранной системы; в качестве примера можно использовать описание Amazon S3 Object Lock. Попытайтесь удалить именно защищённую версию объекта: в S3 обычный запрос без идентификатора версии может лишь создать маркер удаления. Проверьте действия обычной рабочей роли, роли резервного копирования и аварийного администратора. В S3 режим governance допускает явный обход специальным полномочием, а compliance не позволяет сократить срок хранения, поэтому последний нельзя включать неосторожно. Для офлайн-варианта отключите носитель или хранилище от рабочих учётных данных и подтвердите, что скомпрометированная рабочая роль до него не добирается. Запишите также, где хранится ключ шифрования: неизменяемая копия без доступного ключа не восстанавливается.
5. План BC/DR на две страницы. Сделайте краткую управляющую карту: область действия, владелец и версия; целевые RPO/RTO и минимальный уровень сервиса; выбранная стратегия и схема копий; критерии объявления аварии; роли и внешние каналы связи; порядок критичных зависимостей; условия переключения и возвращения; дата и результат последних учений и дата следующих. Две страницы не заменяют подробных инструкций — они должны содержать проверенные ссылки на них и оставаться доступными вне основной среды.

Итоги

• RPO задаёт допустимую точку восстановления данных, RTO — срок возврата сервиса к согласованному уровню. Цели выводят из анализа влияния на бизнес, а их достижимость проверяют измерениями.
• Правило 3-2-1 помогает разнести копии; расширение 3-2-1-1-0 добавляет офлайн- или неизменяемый экземпляр и проверку без обнаруженных ошибок. Независимость доменов отказа и управления важнее формального числа копий.
• Репликация повышает доступность в предусмотренных доменах, но переносит логическую порчу. Исторические изолированные копии решают другую задачу; снимок становится частью бэкапа только при подходящей согласованности, изоляции и проверке.
• Четыре стратегии DR различаются объёмом заранее работающего резерва, стоимостью и сложностью. Ни название стратегии, ни схема поставщика не гарантируют RPO/RTO без испытаний.
• Проверка формата копии, полное восстановление, настольные учения, переключение с возвращением и контролируемые эксперименты находят разные классы ошибок. Результат — измерения и задачи с ответственными.
• Непрерывность бизнеса шире восстановления ИТ: нужны полномочия и внешняя связь, граф зависимостей, минимальный уровень сервиса и доступный вне основной среды план.

Литература

1. ISO 22301:2019, "Security and resilience — Business continuity management systems — Requirements" (с поправкой 2024 года) — рамка управления непрерывностью бизнеса.
2. NIST SP 800-34 Rev. 1, "Contingency Planning Guide for Federal Information Systems" — BIA, цели восстановления, разработка и проверка плана.
3. CISA, #StopRansomware Guide — изолированные и зашифрованные копии, регулярная проверка восстановления и защита от удаления.
4. "Disaster Recovery of Workloads on AWS" — один из источников классификации backup and restore, pilot light, warm standby и multi-site active-active; численные оценки зависят от реализации.
5. B. Beyer et al. (ред.), "Site Reliability Engineering," O'Reilly, 2016 — бэкапы, восстановление и учения DiRT; электронная версия книги.
6. Материалы ЦИТадели: глава 4 о согласованности, глава 5 о репликации, глава 11 о проверке гарантий, «Облака: устройство и модели» и «Надёжность поверх ненадёжной сети».