RPO · ДАННЫЕ
Какие изменения можно потерять?
При RPO 15 минут требуется возможность восстановить данные с отставанием не более 15 минут от момента сбоя в согласованном сценарии.
ПРАКТИКА ВОССТАНОВЛЕНИЯ
RPO и RTO: как задать цели и проверить восстановление
Сколько изменений допустимо потерять и сколько времени сервис может быть недоступен? Разбираем разницу на временной шкале и показываем, как сравнить требования с результатом теста.
Редакция SecRadar · 1 октября 2026
Чем отличаются RPO и RTO
RPO (Recovery Point Objective) — максимально допустимый интервал потери изменений данных, выраженный во времени. RTO (Recovery Time Objective) — целевой предел времени от прерывания работы до восстановления согласованного уровня сервиса. Это требования, с которыми сравнивают результат восстановления, а не показатели скорости конкретного продукта. Определения приведены в документации AWS по аварийному восстановлению.
RTO · ВРЕМЯ
Когда пользователи смогут работать?
При RTO 60 минут сервис должен вернуться к согласованной работе не позднее чем через час после прерывания.
RPO не измеряется в гигабайтах. Одинаковые 15 минут могут означать десять изменений в одном приложении и тысячи операций в другом. Поэтому рядом с интервалом полезно записывать, какие операции будут потеряны и можно ли их восстановить из независимого источника.
Пример: цель выполнена по данным, но нарушена по времени
Учебный сценарий: сервис обработки заказов. Целевые значения — RPO 15 минут и RTO 60 минут. При проверке восстановлены все подтверждённые операции до 09:50 включительно; более поздние изменения в восстановленной системе отсутствуют.
- 09:50Последнее восстановленное согласованное состояние
- 10:00Прерывание работы сервиса
- 11:15Сервис принят после контрольной операции
10 минут потери изменений
10:00 − 09:50 = 10 минут.
Цель RPO выполнена: 10 ≤ 15 минут.
75 минут до восстановления
11:15 − 10:00 = 75 минут.
Цель RTO не выполнена: 75 > 60 минут.
В отчёте лучше разделить четыре поля: целевой RPO, наблюдаемый интервал потери изменений, целевой RTO и фактическое время восстановления. Так результат теста не подменяет исходное требование.
Для расчёта используйте время состояния данных, до которого действительно удалось восстановиться. Время завершения задания резервного копирования может отличаться от этой точки. Если операция восстановления началась в 10:20, первые 20 минут простоя тоже входят в пример: отсчёт здесь задан от прерывания сервиса, а не от нажатия кнопки восстановления.
Как определить RPO и RTO для своего сервиса
Одной формулы, которая назначает всем приложениям правильные значения, нет. Сначала владелец процесса определяет допустимые последствия сбоя, затем ИТ проверяет достижимость требований и стоимость решения.
- Опишите результат для пользователя. Например, «оператор может найти заказ, изменить его и получить подтверждение». Запущенная виртуальная машина ещё не доказывает выполнение этой задачи.
- Укажите сценарий. Отказ одной ВМ, потеря площадки и восстановление после повреждения данных требуют разных проверок. Не переносите результат одного теста на все аварии.
- Согласуйте потерю изменений. Какие записи можно повторить вручную, какие сверить с внешней системой, а какие потерять нельзя? Запишите допустимый интервал и последствия.
- Согласуйте время простоя. Учитывайте работу людей в обход системы, накопление очереди и зависимые процессы. Уточните, какая функциональность обязательна для приёмки.
- Проверьте зависимости и ресурсы. Учтите идентификацию, DNS, сеть, СУБД, ключи шифрования, доступность копий, свободную площадку и сотрудников, которые выполнят восстановление.
- Проведите тест. Если цель недостижима, пересмотрите архитектуру, процедуру или согласованное требование. Не исправляйте целевое значение задним числом, чтобы тест считался успешным.
Например, условные «15 минут / 1 час» выше — исходные условия учебной задачи, а не рекомендация для любой системы заказов.
Как проверить цели восстановлением
Ниже — редакционная форма фиксации результата. Сама процедура пилота и заполняемый CSV уже есть в протоколе проверки восстановления.
| Поле | Пример или способ проверки |
|---|---|
| Сервис и сценарий | Заказы; недоступность основной площадки; объём и конфигурация теста. |
| Цели и критерий приёмки | RPO 15 минут, RTO 60 минут; чтение и запись заказа доступны, обязательные интеграции работают. |
| Начало простоя | 10:00. Единый источник времени и часовой пояс для всех отметок. |
| Восстановленная точка данных | 09:50. Подтверждена журналом операций и сверкой восстановленных записей. |
| Возврат сервиса | 11:15. Контрольная операция выполнена, результат принят ответственным. |
| Результат и отклонения | 10 минут потери изменений, 75 минут восстановления; RPO выполнена, RTO нарушена на 15 минут. |
| Следующее действие | Определить задержавший этап, назначить владельца исправления и повторить проверку. |
Проводите восстановление в согласованной изолированной среде. До запуска отключите нежелательные рассылки, платежи и задания в рабочие системы. Сохраняйте журнал этапов: обнаружение, принятие решения, подготовка площадки, возврат данных, запуск зависимостей, проверка приложения. Если этапы идут параллельно, полное время считают по началу и концу процесса, а не складывают пересекающиеся интервалы.
Что чаще всего искажает результат
Копия каждые 15 минут гарантирует RPO 15 минут?
Нет. Расписание нужно сопоставить с фактическими доступными точками восстановления: задания могут завершаться с ошибкой, передача — задерживаться, цепочка — быть неполной. Проверяйте восстановление данных, включая необходимый журнал транзакций.
Если виртуальная машина запущена, RTO достигнута?
Только если именно это было согласованным результатом. Для прикладного сервиса обычно нужна проверка пользовательской операции, данных и обязательных зависимостей.
Репликация заменяет резервное копирование?
Не во всех сценариях. Ошибочное изменение или удаление может попасть и в реплику. Резервная копия позволяет вернуться к сохранённому состоянию в пределах доступных точек и срока хранения. Различия описаны в Microsoft Learn.
SLA доступности — это RTO?
Не обязательно. Процент доступности за месяц и время восстановления после конкретного сбоя — разные показатели. Проверяйте, какое событие начинает отсчёт, что считается восстановлением и какие исключения определены в соглашении.
Успешный тест гарантирует такой же результат после атаки?
Нет. При атаке может потребоваться найти незатронутую точку, восстановить доверие к среде и проверить учётные данные. Тест подтверждает только проверенные условия; сценарий повреждения данных нужно рассматривать отдельно.
От требований к выбору системы
Когда цели и сценарии зафиксированы, их можно использовать как условия пилота. Сравнивайте результаты при одинаковом объёме данных, составе сервиса и критерии готовности.
Какие системы резервного копирования подходят для вашей инфраструктуры →
Источники и границы материала
Определения сверены 1 октября 2026 года. Пример времени, порядок согласования и форма проверки разработаны редакцией SecRadar; это не результаты испытаний продуктов и не нормативные требования.