Introducción

Cuando diseñás un sistema de producción, nunca pensás en el momento en que algo va a fallar, pero sí tenés que pensar en cuán rápido podés recuperarte después de un incidente. Las métricas que guían esa recuperación son el RPO (Recovery Point Objective) y el RTO (Recovery Time Objective). Son los pilares sobre los que se construye cualquier estrategia de disaster recovery, ya sea que estés apuntando a una restauración casi instantánea o permitiendo alguna pérdida de datos aceptable.

Este artículo es para desarrolladores, arquitectos de infraestructura y cualquier persona que tenga que diseñar, probar o documentar un plan de continuidad de negocio. Vas a aprender a definir RPO y RTO, a traducir esas definiciones en decisiones técnicas concretas, y a simular algunos cálculos comunes con código ejecutable en Python. Al finalizar, vas a poder asignar niveles realistas a tus servicios y justificar las inversiones en réplicas, snapshots y automatización.

¿Qué es el RPO?

El RPO indica cuánta pérdida de datos estás dispuesto a tolerar después de un fallo. Si un servidor se reinicia y tenés una réplica que está 5 segundos detrás, tu RPO es de 5 segundos: podés perder hasta ese lapso de datos sin que el negocio se vea afectado.

• RPO bajo → Se necesita replicación continua o escritura en memoria distribuida.
• RPO alto → Se puede usar snapshots periódicos, réplicas nocturnas o incluso restauraciones desde backups.

El RPO se mide en tiempo (segundos, minutos) porque lo que importa es cuánto dato no se guardó antes de que el fallo ocurra. En términos prácticos, si tu tienda web registra 10 000 transacciones por hora y solo podés tolerar la pérdida de hasta 100 transacciones, tu RPO debe ser ≤ 36 segundos (100 / 3600 × 3600). Si decides permitir la pérdida de 500 transacciones, podés relajar el RPO a 180 segundos.

¿Qué es el RTO?

El RTO indica cuánto tiempo está tu servicio permitido estar fuera de servicio antes de que el negocio sufra un impacto inaceptable. No se trata de pérdida de datos, sino de disponibilidad.

• RTO bajo → Se necesita una activación automática, pruebas de salud y conmutación sin intervención humana.
• RTO alto → Se puede aceptar un proceso manual, restauraciones desde backups que tardan horas, o incluso depender de un centro de datos secundario que no está geográficamente cercano.

El RTO se mide en minutos u horas. Por ejemplo, si tenés un acuerdo de nivel de servicio (SLA) que promete 99.9 % de disponibilidad mensual (~7.2 horas de tolerancia), podés establecer un RTO de 30 minutos para cada incidente, asumiendo que corregirás el fallo o restaurarás el servicio dentro de ese lapso.

Diseño de un plan basado en RPO y RTO

Mapear RPO vs. RTO a técnicas concretas es donde la teoría se encuentra con la práctica. A continuación, un marco rápido que podés usar en cualquier organización.

1. Definir el impacto del negocio

   • Identificar los servicios críticos.
   • Estimar la pérdida de ingresos o daño a la reputación por unidad de tiempo.

2. Asignar RPO y RTO por servicio

   • Usa métricas cuantitativas (ej: ≤ 10 segundos de pérdida de datos, ≤ 5 minutos de inactividad) y calidades cualitativas (ej: "no crítico", "crítico").

3. Elegir la estrategia de replicación

   • Continuación en tiempo real (Kafka, MySQL binlog, réplicas síncronas) → RPO de pocos segundos.
   • Snapshots programados (instantáneas de VM, backups LVM) → RPO de minutos a horas.
   • Async replication (réplicas geografías) → RPO de minutos.

4. Elegir el enfoque de recuperación

   • Conmutación automática (balanceadores de carga con health checks) → RTO bajo.
   • Activación manual (scripts de restauración) → RTO moderado.
   • Manual completo (restauración desde cinta) → RTO alto.

5. Documentar el procedimiento

   • Flujogramas de conmutación.
   • Listas de verificación de pruebas de restauración.
   • SLA internamente acordados.

6. Probar y ajustar

   • Simular fallos en intervalos controlados.
   • Medir el RPO real (tamaño de la brecha de replicación) y el RTO real (tiempo desde la activación hasta el servicio en línea).
   • Ajustar las métricas si los resultados no cumplen con lo planificado.

Ejemplos prácticos con código

A continuación, dos escenarios reales escritos en Python que calculan RPO y RTO en base a suposiciones de diseño. Ejecutá el bloque para ver los valores resultantes y los comentarios sobre la estrategia recomendada.

# Ejemplo: Cálculo de RPO y RTO para un servicio web simple
import math

def calculate_rpo_rto(daily_writes, replication_lag, recovery_method, mttr):
    """
    daily_writes: número de escrituras por día (ej: 10_000)
    replication_lag: segundos de latencia en la réplica (ej: 5)
    recovery_method: "snapshot" o "continuous"
    mttr: tiempo medio de reparación en segundos (ej: 300)
    """
    if recovery_method == "snapshot":
        # Se asume un snapshot cada hora
        rpo = 3600  # segundos (1 hora)
    else:
        rpo = replication_lag

    rto = mttr
    return rpo, rto

# Escenario 1: Tienda e‑commerce de alto volumen
rpo1, rto1 = calculate_rpo_rto(
    daily_writes=10_000,
    replication_lag=5,
    recovery_method="continuous",
    mttr=300
)
print(f"Escenario 1 – RPO: {rpo1} segundos, RTO: {rto1} segundos")
# Salida esperada: Escenario 1 – RPO: 5 segundos, RTO: 300 segundos

# Escenario 2: CRM legacy que solo permite snapshots horarios
rpo2, rto2 = calculate_rpo_rto(
    daily_writes=5_000,
    replication_lag=0,
    recovery_method="snapshot",
    mttr=1800
)
print(f"Escenario 2 – RPO: {rpo2} segundos, RTO: {rto2} segundos")
# Salida esperada: Escenario 2 – RPO: 3600 segundos, RTO: 1800 segundos

Explicación de la salida

• En el Escenario 1, la replicación continua permite un RPO de solo 5 segundos (el retardo de red). El RTO de 300 segundos (5 minutos) asume un proceso de reparación automatizado.
• En el Escenario 2, el uso de snapshots obliga a un RPO de 1 hora (3600 segundos), porque cualquier fallo entre snapshots se pierde. El RTO se duplica a 30 minutos (1800 segundos) porque la restauración desde un snapshot es más lenta.

Si querés ajustar cualquiera de estos valores, modificá los argumentos en la función y volvé a ejecutar. Esto demuestra que RPO y RTO son una elección de diseño iterativa, no un número fijo.

Buenas prácticas y errores comunes

1. Definir RPO/RTO juntos

   • Pensar en el impacto conjunto de pérdida de datos y tiempo de inactividad. Un servicio con RPO bajo pero RTO alto aún puede ser inaceptable si necesitás los datos de inmediato.

2. Evitar objetivos poco realistas

   • Un RPO de 0 segundos es técnicamente posible (réplicas síncronas), pero puede matar el rendimiento. Asegurarse de que el RPO se base en necesidades reales, no solo en el estado del arte.

3. Documentar supuestos

   • El RPO depende del retardo de replicación, del intervalo de snapshots, del ancho de banda de red, etc. Dejar estos datos en documentos living spec.

4. Incluir pruebas de restauración

   • Un RTO no documentado no es un objetivo; es una esperanza. Programar restauraciones periódicas y medir el RTO real.

5. Usar automatización para reducir el RTO

   • Los scripts de conmutación automática pueden recortar el RTO de horas a minutos. Invertir en un sistema de orquestación (Terraform, Ansible, CloudFormation) mejora la confiabilidad.

6. Probar bajo estrés

   • El retardo de red puede aumentar durante un desastre (cable submarino cortado). Simular un ancho de banda reducido para validar que los objetivos se mantienen.

7. Revisar después de cada incidente

   • Después de un fallo real, comparar el RPO/RTO planificado con el real. Ajustar las expectativas o la estrategia.

8. Evitar el sobre‑ingeniería

   • Los servicios no críticos pueden tener RTOs de días. Priorizar la inversión en aquellos que afectan directamente los ingresos.

Conclusión

RPO y RTO son los dos pilares que dan forma a cualquier estrategia de disaster recovery. Definiendo cuánta pérdida de datos podés tolerar (RPO) y cuánto tiempo podés estar fuera de línea (RTO), podés elegir la técnica de replicación, el enfoque de recuperación y el nivel de automatización adecuado para cada servicio.

El ejemplo en código demuestra que calcular estos valores es sencillo: solo necesitas entender tu arquitectura y los tiempos de reparación esperados. Usar esos cálculos para guiar decisiones de diseño mantiene los planes de contingencia realistas y justifica las inversiones en disponibilidad.

Cuando diseñás o revisas un plan de recuperación ante desastres, seguí estos pasos:

1. Identificar los servicios críticos.
2. Asignar RPO/RTO basado en el impacto en el negocio.
3. Mapear a estrategias de réplicas y recuperación.
4. Documentar, probar y medir regularmente.

Con un enfoque basado en datos y una cultura de pruebas continuas, podés mantener tu infraestructura resistente, reduciendo tanto la pérdida de datos como el tiempo de inactividad cuando lo inesperado ocurre.

Próximos pasos

• Modelar tu propia arquitectura con la función de Python para obtener valores concretos de RPO/RTO.
• Implementar un pipeline de pruebas de restauración que capture RPO/RTO reales.
• Ajustar los acuerdos de nivel de servicio (SLA) internamente en base a tus mediciones.
• Considerar el uso de herramientas de observabilidad (ej: Prometheus + Grafana) para hacer tracking continuo del retardo de replicación y los tiempos de reparación.

Al iterar sobre estos pilares, vas a poder diseñar sistemas que no solo resisten los fallos, sino que también mantienen el negocio funcionando sin interrupciones, protegiendo tanto los datos como la confianza de los usuarios.