recovery point objective, RPO

Целевая точка восстановления (RPO) определяет, насколько «свежими» должны быть данные после восстановления, чтобы организация могла возобновить конкретную деятельность и продолжить работу с приемлемыми последствиями. По сути, RPO задаёт допустимую потерю данных во времени: если RPO составляет 15 минут, то при сбое допускается потеря изменений, сделанных за последние 15 минут до момента инцидента или катастрофы, при условии что деятельность сможет работать после возобновления. В ITSM RPO обычно формируется на основе анализа влияния на бизнес (BIA) и оценки риска, затем закрепляется как часть требований гарантии для ИТ-услуги и используется при проектировании решений по восстановлению, включая резервное копирование, репликацию, журналы транзакций и процедуры восстановления. RPO применяется не только к «системе в целом», а к конкретным видам информации и потокам обработки (например, заказы, платежи, учетные записи). Вне области RPO находятся скорость восстановления (это целевое время восстановления, RTO), а также детальная реализация средств защиты данных и юридическая классификация данных; RPO задаёт требование к результату восстановления по точке данных, а не конкретный инструмент или расписание.

Целевую точку восстановления часто путают с целевым временем восстановления (RTO): RPO отвечает на вопрос «до какого момента должны восстановиться данные», а RTO — «как быстро должна восстановиться работоспособность». Возможна ситуация, когда RTO маленькое, но RPO большое (быстро поднимаем сервис, но с потерей части данных), и наоборот (данные почти не теряем, но восстановление занимает дольше). Частая ошибка — трактовать RPO как «частоту резервного копирования»: копии могут делаться каждые 15 минут, но фактический RPO будет хуже из‑за задержек репликации, окон консистентности, ошибок процедур, шифрования или времени на фиксацию транзакций. Также ошибочно назначать «RPO = 0» без проверки реалистичности: нулевая потеря данных требует синхронной репликации или иных дорогих решений и может ухудшать производительность и доступность. Ещё одна ловушка — задавать RPO на уровне приложения, игнорируя зависимости: база данных, очереди сообщений, файловые хранилища и интеграции должны иметь согласованную целевую точку восстановления, иначе после восстановления деятельность не сможет корректно функционировать. Наконец, RPO нельзя считать «обещанием SLA» без регулярного тестирования планов восстановления после катастрофы и контроля фактических метрик.