2026-11-02T09:00:00+03:00

02.11.2026 09:00

RTO и RPO — две метрики, которые определяют, как компания переживёт сбой. Первая задаёт допустимое время простоя, вторая — допустимый объём потери данных. Без них резервное копирование превращается в набор файлов, а план восстановления — в предположение, которое проверяется только во время аварии.

Эти показатели нужны не только крупным банкам или маркетплейсам. Интернет-магазин, CRM, корпоративная почта, сайт, 1С, база клиентов, складская система и внутренняя база знаний имеют разную ценность для бизнеса. Значит, для них не может быть одного общего требования «восстановить всё как можно быстрее».

RTO и RPO определяет бизнес, а не только ИТ-отдел. Техническая команда должна оценить, можно ли достичь нужных показателей на текущей инфраструктуре и во сколько обойдётся их соблюдение.

Что такое RPO

RPO, Recovery Point Objective — целевая точка восстановления. Она показывает, за какой период компания готова потерять данные при аварии.

RPO обычно выражают во времени: 15 минут, один час, четыре часа или сутки.

Если RPO базы данных установлен на один час, при серьёзном сбое допустимо потерять изменения, сделанные не более чем за последний час до аварии.

Простой пример: резервная копия создаётся раз в сутки, в 00:00. Если сервер выйдет из строя в 23:59, а других копий и репликации нет, компания может потерять почти весь рабочий день. Фактический RPO в таком сценарии близок к 24 часам.

Чем ниже RPO, тем чаще нужно создавать копии или синхронизировать данные с резервным контуром. Ночные бэкапы подходят для части систем, но не для тех, где каждая транзакция, заказ или изменение остатка имеет значение.

Что такое RTO

RTO, Recovery Time Objective — целевое время восстановления. Это срок, за который сервис должен снова стать доступным после аварии.

Если RTO составляет четыре часа, это значит, что за четыре часа нужно не просто развернуть резервную копию, а вернуть сервис в рабочее состояние: обнаружить инцидент, принять решение о восстановлении, подготовить инфраструктуру, восстановить данные, проверить их целостность, настроить сервисы и переключить трафик.

Поэтому скорость восстановления одного дампа базы данных нельзя автоматически считать RTO.

Реальное RTO =
время обнаружения сбоя
+ время диагностики и принятия решения
+ подготовка резервной инфраструктуры
+ восстановление данных и сервисов
+ настройка конфигураций и доступов
+ проверка работоспособности
+ переключение трафика
+ прогрев системы

Например, дамп PostgreSQL может разворачиваться два часа. Но если до этого нужно диагностировать проблему, подготовить сервер, восстановить секреты и конфигурации, проверить данные, переключить DNS или балансировщик, фактическое время простоя окажется заметно больше.

Чем RTO отличается от RPO

Разница между метриками проста:

• RPO отвечает на вопрос: «За какой период мы можем потерять данные?»
• RTO отвечает на вопрос: «Как долго сервис может быть недоступен?»

Эти параметры связаны, но не заменяют друг друга. Можно быстро поднять сервис из резервной копии, но потерять данные за несколько часов. Можно почти не терять данные благодаря репликации, но долго восстанавливать приложение, доступы, сетевые настройки и зависимости.

RPO определяет требования к сохранности данных. RTO — требования к скорости возвращения сервиса в работу.

Почему нельзя назначить одинаковые RTO и RPO для всех систем

Поддерживать резервный контур с минимальным простоем и почти нулевой потерей данных дорого. Для каждой системы нужно соотносить стоимость защиты с последствиями сбоя.

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

У одной компании могут быть разные значения RTO и RPO:

• для базы заказов — RPO 15 минут и RTO 1 час;
• для корпоративной почты — RPO 1 час и RTO 4 часа;
• для сайта-визитки — RPO сутки и RTO 8 часов;
• для архива старых документов — RPO сутки и RTO несколько дней.

Это не универсальные нормативы, а примеры. Реальные значения зависят от бизнес-процесса, объёма данных, требований законодательства, архитектуры и бюджета.

Какие технологии влияют на RTO и RPO

Резервное копирование

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

Резервная копия, которую ни разу не восстанавливали, не подтверждает готовность к аварии. Она может оказаться неполной, повреждённой, слишком старой или потребовать больше времени на развёртывание, чем предполагает план.

Репликация

Репликация переносит изменения на резервный сервер или площадку. При синхронной репликации можно приблизить RPO к нулю для подтверждённых операций. Асинхронная репликация обычно проще и быстрее в работе, но допускает отставание между основной и резервной системами.

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

Горячий и тёплый резерв

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

Чем ниже целевые RTO и RPO, тем выше требования к архитектуре, автоматизации, каналам связи, хранилищам и регулярным проверкам.

Как определить RTO и RPO для компании

1. Составьте перечень систем и зависимостей. Включите приложения, базы данных, очереди, хранилища файлов, внешние API, DNS, почту и сервисы авторизации.
2. Оцените последствия простоя. Определите, что произойдёт, если система будет недоступна 15 минут, час, четыре часа или сутки.
3. Разделите сервисы по критичности. Необязательно рассчитывать уникальную стратегию для каждого компонента. Удобно сформировать несколько классов критичности.
4. Согласуйте допустимые потери. Владелец процесса должен определить, какие данные можно восстановить вручную, а какие потерять нельзя.
5. Подберите техническое решение. Для одних систем достаточно резервных копий, для других потребуются журналирование транзакций, репликация, резервная площадка или горячий контур.
6. Проверьте расчёты тестом. Измерьте фактические RTO и RPO на сценарии восстановления, а не по теоретическим оценкам.

Что включить в план аварийного восстановления

План Disaster Recovery должен описывать не только команду запуска бэкапа. В нём нужны ответы на практические вопросы:

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

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

Как проверить, что целевые показатели достижимы

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

После теста стоит зафиксировать:

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

Каждое расхождение между планом и результатом теста — это не провал, а конкретная задача по улучшению защиты.

Главное

RPO показывает, сколько данных бизнес готов потерять. RTO — сколько времени он готов ждать восстановления сервиса. Эти показатели нельзя выбрать «на глаз» и нельзя гарантировать одними бэкапами.

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