RPO y RTO son las dos métricas que transforman un discurso genérico de "queremos alta disponibilidad" en un contrato técnico claro. Determinan cuánto dato puedes perder, cuánto tiempo puedes estar caído y, por lo tanto, cuánto debes invertir en respaldo y recuperación.
En esta guía te enseñamos a definir RPO y RTO realistas, a calcular el costo del downtime y a traducirlos en decisiones de arquitectura concretas.
Contenido
Definiciones precisas de RPO y RTO
RPO (Recovery Point Objective)
Es la cantidad máxima de datos, medida en tiempo, que la empresa puede permitirse perder. Si tu RPO es 1 hora, tus respaldos deben capturar cambios al menos cada hora. Un incidente a las 15:00 con RPO de 1 h implica que aceptas perder los datos entre 14:00 y 15:00.
RTO (Recovery Time Objective)
Es el tiempo máximo aceptable desde que ocurre la caída hasta que el servicio está operativo nuevamente. Incluye detección, notificación, decisión, ejecución y validación. Si tu RTO es 4 h y el servicio cayó a las 10:00, debe estar funcional a las 14:00.
Diferencias clave y errores comunes
| Aspecto | RPO | RTO |
|---|---|---|
| Unidad | Tiempo de datos perdidos | Tiempo de recuperación |
| Determinado por | Frecuencia de backup/replicación | Arquitectura de recuperación |
| Inversión principal | Almacenamiento, ancho de banda | Compute en standby, automatización |
| Impacto si se excede | Pérdida de datos (irrecuperables) | Pérdida de facturación y reputación |
Un error común es fijar RPO y RTO idénticos para todos los sistemas. Resulta carísimo e innecesario. Usa el BIA (ver guía de DRP) para clasificar sistemas en tiers.
Cómo calcular RPO y RTO en tu empresa
No se calculan en TI: se negocian con el negocio. El proceso:
- Entrevista con dueños de proceso: pregunta "si este sistema cayera ahora, ¿en cuánto tiempo te genera un daño irreversible?"
- Cuantifica el costo por hora: facturación perdida + multas + costo de personal parado + daño reputacional
- Evalúa dependencias: un ERP sin base de datos no sirve; RTO del ERP = max(RTO_app, RTO_db)
- Define tiers: agrupa sistemas con RPO/RTO similares
- Valida con CFO y Gerencia: los RTOs más agresivos requieren inversión que deben aprobar
Ejemplo: empresa retail chilena
| Sistema | RPO | RTO | Justificación |
|---|---|---|---|
| E-commerce + pasarela pago | 5 min | 30 min | $2M/hora de venta online |
| ERP / facturación SII | 15 min | 2 h | Obligación tributaria en curso |
| CRM comercial | 1 h | 4 h | Impacto diferido |
| Intranet / RRHH | 4 h | 8 h | Proceso interno no crítico |
| Archivo histórico | 24 h | 48 h | Consulta ocasional |
Calcular el costo del downtime
Fórmula base:
Un e-commerce con $100M/día de venta y 10 horas operativas pierde $10M/hora solo en ventas. Si el RTO es 4 horas, el incidente cuesta $40M. Una infraestructura de DR que costaría $3M/año se paga en un solo evento.
Cómo traducir RPO/RTO a arquitectura
| RPO objetivo | Tecnología sugerida |
|---|---|
| 24 h | Backup diario con Veeam/Vembu |
| 4-8 h | Backup incremental frecuente |
| 1 h | Snapshot de storage + replicación async |
| 5-15 min | CDP (Continuous Data Protection) |
| 0 | Replicación síncrona (stretched cluster) |
| RTO objetivo | Tecnología sugerida |
|---|---|
| 24 h+ | Restore desde backup a hardware nuevo |
| 4-8 h | Instant Recovery de Veeam + cloud |
| 1 h | DRaaS con orquestación (Azure Site Recovery) |
| <15 min | Cluster activo-activo, load balancer geo-distribuido |
Cuando la solución parece desproporcionada al costo, probablemente el RTO está sobre-especificado. Vuelve a la conversación de negocio. Nuestro servicio de Respaldo y Monitoreo construye estos diseños con soluciones apropiadas a cada tier.
MTTR, MTBF y otras métricas relacionadas
- MTTR (Mean Time To Recovery): medido en ejercicios reales; debería ser ≤ RTO
- MTBF (Mean Time Between Failures): frecuencia promedio de fallas
- WRT (Work Recovery Time): tiempo de re-ingresar datos perdidos manualmente tras el restore
- MTD (Maximum Tolerable Downtime): límite absoluto antes de daño irreversible; siempre > RTO
¿Definimos tus RPO y RTO con tu equipo?
Facilitamos BIAs, medimos MTTR reales y diseñamos arquitecturas de respaldo a la medida.
Hablar con UpTech →Preguntas frecuentes
¿Qué significan RPO y RTO?
RPO (Recovery Point Objective) es la cantidad máxima de datos tolerable de perder. RTO (Recovery Time Objective) es el tiempo máximo aceptable de caída del servicio.
¿Cuál es un RTO típico para un ERP?
Entre 1 y 4 horas en empresas medianas. Sistemas críticos de gran empresa apuntan a <1 h con replicación síncrona y arquitectura activo-activo.
¿Cómo calculo el costo del downtime?
Suma facturación por hora perdida, costo de personal parado, multas contractuales y pérdida reputacional estimada. Para e-commerce y retail el cálculo es directo; para B2B suele requerir modelar impacto diferido.
¿RPO puede ser cero?
En teoría sí, con replicación síncrona. En la práctica tiene costos de latencia e infraestructura muy altos y normalmente se reserva para transacciones financieras críticas.
¿Cada cuánto reviso RPO y RTO?
Mínimo anual, o cuando cambian procesos críticos del negocio. Un RTO establecido en 2018 rara vez sigue siendo realista en 2025.