Si ya leíste RPO y RTO en cristiano, tienes las dos siglas que todo el mundo cita. Pero en una llamada de continuidad seria van a aparecer dos más —MTD y WRT— y suelen decirse como si todos las conocieran. No es jerga de adorno: son las que explican por qué a veces "el sistema ya está arriba" y el negocio sigue detenido. Aquí está el mapa completo, en una sola línea de tiempo.
El techo que manda: MTD
El MTD (Maximum Tolerable Downtime, máximo tiempo tolerable de caída) es el límite duro: cuánto puede estar detenido un proceso antes de que el daño sea irreversible —clientes que no regresan, multas, un contrato perdido. No es un objetivo que eliges; es una restricción que el negocio tiene, la reconozcas o no. Y es el padre de todas las demás métricas: el RTO tiene que caber dentro del MTD, no al revés. Este número no se adivina, sale del análisis de impacto al negocio.
El MTD se parte en dos: RTO + WRT
Aquí está la pieza que casi nadie explica. El tiempo total que tienes (el MTD) se divide en dos tramos:
- RTO (Recovery Time Objective): el tiempo para tener el sistema técnicamente arriba —servidores encendidos, datos restaurados, servicios respondiendo.
- WRT (Work Recovery Time): lo que viene después de que el sistema está arriba y antes de que el negocio realmente opere: validar que los datos estén íntegros, procesar lo que quedó a medias, reconectar integraciones, que la gente vuelva a trabajar en él con confianza.
La ecuación es MTD = RTO + WRT, y explica un malentendido caro: el equipo técnico anuncia "ya está recuperado" al terminar el RTO, pero el negocio aún no factura ni atiende porque falta todo el WRT. Si al dimensionar tu recuperación gastas todo el MTD en el RTO y te olvidas del WRT, llegas técnicamente a tiempo y operativamente tarde.
Y en paralelo: el RPO
Mientras RTO, WRT y MTD miden tiempo hacia adelante (cuánto tardas en volver), el RPO (Recovery Point Objective) mira hacia atrás: cuántos datos, medidos en tiempo, puedes permitirte perder. Un RPO de una hora significa que tus respaldos o réplicas deben ser lo bastante frecuentes para no perder más de una hora de trabajo. El RPO no depende de qué tan rápido recuperas, sino de cada cuánto proteges los datos —y por eso se resuelve con la frecuencia de respaldo o replicación, no con la velocidad de arranque.
La línea de tiempo, de una mirada
| Métrica | Mira hacia | Responde | Se resuelve con |
|---|---|---|---|
| RPO | Atrás (antes del desastre) | ¿Cuántos datos puedo perder? | Frecuencia de respaldo/replicación |
| RTO | Adelante | ¿En cuánto tengo el sistema arriba? | Estrategia y sitio de recuperación |
| WRT | Adelante | ¿En cuánto vuelvo a operar de verdad? | Validación, reproceso, reconexión |
| MTD | El techo total | ¿Cuánto aguanta el negocio? (= RTO + WRT) | El BIA lo define; no se elige |
La pregunta que conviene hacerse
La trampa no está en no conocer RPO y RTO —eso ya lo tiene medio mundo. Está en fijar un RTO ajustado, cumplirlo, y aun así llegar tarde porque nadie contó el WRT ni verificó que cupiera bajo el MTD. Así que la pregunta útil es: cuando digamos "ya está recuperado", ¿el negocio podrá operar de inmediato, o todavía faltará medio día de validar y reprocesar que nadie presupuestó? Dimensionar esas cuatro métricas juntas —y traducirlas a un sitio de recuperación y un esquema de DRaaS que las respete— es la diferencia entre un plan que suena bien y uno que aguanta el peor día.