RTO (Recovery Time Objective) — ключевой показатель плана аварийного восстановления (Disaster Recovery Plan). Определяет максимальное время, в течение которого система может быть недоступна после сбоя, прежде чем это нанесёт неприемлемый ущерб бизнесу.
Как работает
RTO устанавливается исходя из бизнес-требований: для интернет-магазина каждый час простоя = потерянные заказы; для корпоративного портала 4 часа простоя допустимы. RTO напрямую определяет технические требования к инфраструктуре:
- RTO = 0 мин (непрерывность) — требуется активный/активный кластер, нет переключения.
- RTO = 5–15 мин — активный/пассивный кластер с автоматическим failover (Keepalived, Pacemaker).
- RTO = 1–4 ч — ручное восстановление из снапшота или бэкапа.
- RTO = 24 ч — восстановление из ленточного архива или off-site бэкапа.
RPO (Recovery Point Objective) — дополняющий показатель: максимально допустимая потеря данных во времени. RPO = 0 — нет потери данных (синхронная репликация). RPO = 24 ч — допустима потеря суточного объёма данных (ежедневный полный бэкап).
История
Термины RTO и RPO формализованы в стандартах аварийного восстановления в 1990-х годах. Широко используются в ISO 22301 (Business Continuity Management System, 2012) и NIST SP 800-34 (Contingency Planning Guide for IT Systems, 2010). В SLA хостинг-провайдеры указывают RTO как часть гарантий по уровню сервиса.
RTO и стратегии резервного копирования
Выбор стратегии бэкапа напрямую влияет на RTO. Полный бэкап (Full Backup) даёт минимальное RTO: восстановление — единственная операция. Инкрементальный бэкап снижает объём хранения, но увеличивает RTO: нужно восстановить базовый бэкап плюс цепочку инкрементов. Дифференциальный бэкап — компромисс: восстановление базовый + последний дифференциальный.
Для критичных систем с требованием RTO < 15 минут применяют горячий резерв (hot standby): полная копия системы в готовности, переключение через DNS failover или IP failover. Стоимость такого решения — двойные расходы на инфраструктуру. RAID-массивы снижают RTO при отказе диска: RAID 1 восстанавливает данные с зеркала мгновенно, без простоя.
На что обращать внимание
RTO должен быть задокументирован и протестирован — многие компании устанавливают RTO, но никогда не проверяют, достижим ли он реально. Учения по аварийному восстановлению (Disaster Recovery Drill) рекомендуются раз в полгода. Для VPS: типичный RTO при восстановлении из снапшота — 15–30 минут; из Restic-бэкапа — 1–4 часа в зависимости от объёма данных.
RTO в хостинге
Типичные значения RTO: shared hosting с ручным восстановлением — 4-24 часа, VPS с автоматизированным восстановлением из бэкапа — 30-120 минут, managed Kubernetes с redundancy — 1-10 минут. Master-Slave репликация БД снижает RTO: при отказе мастера promote реплики занимает 1-5 минут. Мониторинг сервера — ключевой компонент: без алертов RTO растёт до времени обнаружения инцидента + времени восстановления. Тест RTO: регулярные drill-упражнения — восстановление из Restic-бэкапа на тестовый VPS с замером времени.