NIST SP 800-34 Rev. 1, документ по планированию восстановления 2010 года, определяет RPO через точку до сбоя, к которой следует восстановить данные. Здесь этот источник используется для смысла термина, не как обязательная норма для любого российского сайта.

Требование задают по данным, а не по названию тарифа

Сначала определите, какие изменения нельзя потерять: заказы, оплату, записи кабинета или загрузки. Разным наборам может понадобиться разная схема. При допустимой потере последних 15 минут RPO можно записать как 15 минут, но это еще не подтвержденная возможность услуги.

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

Учебный пример: расписание не равно достигнутому RPO

Предположим, сбой произошел в 14:00, а последняя пригодная согласованная точка относится к 13:30. Разрыв составляет 30 минут. Для заранее выбранного требования 15 минут такая точка слишком старая. Это придуманный пример расчета, не результат испытания хостинга.

Если архив закончил записываться в 13:45, нельзя автоматически принять 13:45 за состояние данных. Выясните, какой момент представляет копия и можно ли дополнить ее журналами изменений. Время окончания передачи файла и восстановимая точка - разные сведения.

Что нужно подтвердить

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

ПроверкаЧто записать
СоставКакие базы, файлы и журналы входят
ТочкаКакое состояние данных представляет копия
ПропускЧто происходит при неудачном запуске
ПригодностьКто и когда проверяет отдельное восстановление

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

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

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

Для реализации схемы переходите к руководству по резервным копиям. Здесь нет испытаний восстановления или подтвержденных RPO провайдеров. Источники прочитаны 7 октября 2026 года; их определения не изменяют условия вашего договора. Другие определения собраны в словаре хостинга.