Когда сервер с базой данных уходит в даун посреди рабочего дня, первый вопрос, который задаёт бизнес, звучит просто: «Когда всё заработает?». Именно на этот вопрос отвечает показатель RTO (Recovery Time Objective) — целевое время восстановления системы после сбоя. Если термин встретился вам в требованиях заказчика, аудите или при выборе решения для резервного копирования, без чёткого понимания его сути согласовать реалистичный план аварийного восстановления не получится.
В этой статье разберём, что такое RTO на практике, чем он отличается от смежного показателя RPO, как рассчитать допустимое время простоя для конкретного сервиса и какие технические средства помогают уложиться в заданные рамки. Материал ориентирован на системных администраторов, IT-специалистов и владельцев небольшой инфраструктуры.
Что такое RTO и зачем он нужен
Recovery Time Objective — это максимально допустимый промежуток времени между моментом отказа системы и моментом её восстановления до работоспособного состояния. Проще говоря, RTO отвечает на вопрос: «Как долго сервис может не работать, прежде чем простой станет критичным для бизнеса?».
Показатель задаётся не техническими специалистами, а бизнесом, исходя из стоимости простоя. Для интернет-магазина в час пик каждая минута недоступности — это прямые потери заказов, поэтому RTO может измеряться минутами. Для внутренней wiki-энциклопедии компании простой в несколько часов может быть вполне приемлем.
Важно понимать: RTO — это целевое значение, обязательство, а не фактическое время восстановления. Реальное время восстановления (его иногда обозначают как RTA — Recovery Time Actual) нужно периодически измерять на учениях и сравнивать с целевым. Если фактическое время превышает целевое, план аварийного восстановления требует переработки.
Чем RTO отличается от RPO
Эти два показателя постоянно путают, хотя они описывают разные измерения одной и той же проблемы. RPO (Recovery Point Objective) отвечает на вопрос «сколько данных мы готовы потерять?» и измеряется возрастом последней работоспособной резервной копии. RTO отвечает на вопрос «как быстро мы должны всё поднять?».
| Критерий | RTO | RPO |
|---|---|---|
| Что измеряет | Допустимое время простоя | Допустимый объём потери данных |
| Вопрос бизнеса | Когда сервис заработает? | На какой момент восстановятся данные? |
| На что влияет | Скорость процедур восстановления, резервная инфраструктура | Частота резервного копирования, репликация |
| Типичный рычаг | Автоматизация, готовые образы, standby-площадка | Интервал бэкапов, синхронная/асинхронная репликация |
Показатели связаны косвенно: жёсткий RPO (минимальная потеря данных) часто требует репликации в реальном времени, а она же помогает быстрее восстановиться. Но формально они независимы — можно иметь свежие копии данных и при этом долго разворачивать из них рабочую систему.
💡RTO — это про время простоя, RPO — про потерю данных. Согласовывать их нужно вместе, но измерять и проверять — раздельно.