RTO y RPO: cuánto tiempo y cuántos datos puede permitirse perder tu operación

Todas las aplicaciones podrían recuperarse. La pregunta es: ¿cuándo?

Y otra todavía más importante: ¿con cuánta información perdida?

Estas dos preguntas se traducen habitualmente en dos conceptos utilizados en Business Continuity y Disaster Recovery: RTO y RPO.

¿Qué es RTO?

RTO significa Recovery Time Objective. Representa el tiempo objetivo dentro del cual un servicio debería volver a estar disponible después de una interrupción.

En términos simples: ¿cuánto tiempo puede permanecer detenido este proceso antes de que el impacto sea inaceptable?

Alhazmi y Malaiya (2013) relacionan el RTO con el tiempo necesario para restaurar las funciones y volver a disponer del servicio.

¿Qué es RPO?

RPO significa Recovery Point Objective. Ayuda a definir cuánto historial de información puede tolerarse perder.

Si una organización realiza respaldos cada 24 horas y ocurre un incidente justo antes del siguiente backup, potencialmente podría perder casi un día de cambios. Un RPO más exigente requiere mecanismos que reduzcan esa ventana.

RTO no es RPO

Imaginemos:

RTO = 4 horas
RPO = 30 minutos

La organización está diciendo dos cosas distintas.

Primero: necesitamos volver a operar dentro de cuatro horas.

Segundo: no queremos perder más de treinta minutos de información.

Una arquitectura puede cumplir uno y fallar en el otro. Por eso ambos deben definirse por separado.

¿Cómo definirlos?

No debería comenzar por la tecnología. Debería comenzar por el impacto del negocio.

¿Qué pasa si el proceso se detiene?

Evalúa consecuencias como:

• ventas detenidas;
• producción afectada;
• incapacidad de facturar;
• usuarios sin servicio;
• pérdida de información;
• compromisos regulatorios;
• impacto reputacional.

¿Qué datos pueden reconstruirse?

No toda información tiene la misma criticidad. Algunas transacciones podrían volver a ingresarse manualmente. Otras podrían ser imposibles de reconstruir.

¿Qué aplicaciones dependen unas de otras?

Recuperar un sistema sin recuperar sus integraciones puede no devolver realmente el proceso a la operación.

No todas las cargas necesitan el mismo objetivo

Una de las decisiones más costosas sería diseñar todas las aplicaciones con el nivel de recuperación más exigente posible. Una estrategia razonable clasifica cargas según criticidad.

Mohammed (2024) muestra precisamente cómo distintos niveles de criticidad pueden asociarse a diferentes objetivos de RTO y RPO. Una aplicación crítica puede necesitar recuperación en minutos. Un archivo histórico quizá pueda esperar mucho más.

Más exigencia implica más arquitectura

Reducir RTO y RPO normalmente requiere aumentar capacidades como:

• replicación;
• automatización;
• redundancia;
• infraestructura secundaria;
• monitoreo;
• pruebas.

Por eso no debería elegirse un número simplemente porque “suena bien”. Debe existir una justificación de negocio.

La pregunta que debería hacerse cada gerente

Para cada servicio crítico: ¿cuánto tiempo podemos operar sin él?

Y: ¿cuánta información estamos dispuestos a perder?

Cuando esas respuestas están claras, TI puede diseñar una estrategia de recuperación coherente con el negocio. Sin ellas, Disaster Recovery corre el riesgo de convertirse en infraestructura sin un objetivo claro.

Referencias

Alhazmi, O. H., & Malaiya, Y. K. (2013). Evaluating disaster recovery plans using the cloud. Proceedings of the Annual Reliability and Maintainability Symposium.

Mohammed, S. (2024). Resilient multi-region cloud architecture for high availability and disaster recovery. International Journal of Multidisciplinary and Scientific Emerging Research, 12(3). https://doi.org/10.15662/IJMSERH.2024.1203046

Sikha, V. K. (2024). Developing a BCDR solution with Azure for cloud-based applications across geographies. North American Journal of Engineering and Research, 5(2).