Recuperación ante Desastres: RTO, RPO y Runbooks Resilientes

Descripción general

La recuperación ante desastres (DR) es el conjunto de políticas, herramientas y procedimientos que permiten recuperar o mantener en funcionamiento la infraestructura tecnológica crítica para el negocio tras un desastre natural o provocado por humanos. Cuando una región muere o una base de datos se corrompe, DR es lo que decide si pierdes minutos o el negocio.

A continuación: cómo definir los objetivos de recuperación, las estrategias de backup, las arquitecturas multi-región y runbooks que de verdad funcionan.

Cuándo usarla

• Operas un servicio crítico para el negocio donde el tiempo de inactividad es inaceptable
• Necesitas cumplir requisitos regulatorios de protección de datos
• Quieres protegerte contra caídas del proveedor cloud, fallos de región o corrupción de datos
• Estás diseñando o revisando tu estrategia de copias de seguridad y recuperación
• Necesitas definir objetivos RTO y RPO para tu organización

Cuando la estrategia ya existe, la plantilla de plan de recuperación ante desastres la convierte en un documento firmable, y el plan de pruebas programa los simulacros que la mantienen honesta.

Conceptos clave

Concepto	Descripción	Valores Típicos
RTO (Recovery Time Objective)	Tiempo de inactividad máximo aceptable después de un desastre	Minutos a 24 horas
RPO (Recovery Point Objective)	Pérdida máxima de datos aceptable (tiempo desde último backup)	Cero a 24 horas
MTTR (Mean Time to Recovery)	Tiempo promedio para restaurar servicio después de falla	Medido en minutos/horas
MTBF (Mean Time Between Failures)	Tiempo promedio entre fallas del sistema	Medido en días/meses
Failover	Cambio a sistema standby cuando el primario falla	Automático o manual
Failback	Retorno al sistema primario después de recuperación	Planificado y probado

Estrategias de recuperación ante desastres

Estrategia	RTO	RPO	Costo	Descripción
Backup y Restauración	Horas a días	Horas a días	Bajo	Backups periódicos restaurados en nueva infraestructura
Pilot Light	10-60 minutos	Minutos	Medio	Sistemas core siempre ejecutando; escalar bajo demanda
Warm Standby	Minutos	Casi cero	Medio-Alto	Réplica reducida lista para escalar
Hot Standby / Activo-Activo	Casi cero	Casi cero	Alto	Réplica completa sirviendo tráfico activamente
Multi-Región Activo-Activo	Casi cero	Cero	Muy Alto	Todas las regiones sirven tráfico simultáneamente

El espectro también es un eje de presupuesto: cada paso a la derecha compra un RTO/RPO menor a cambio de más coste de infraestructura y operación.

Planificación de DR paso a paso

1. Definir Objetivos de Recuperación

Establece RTO y RPO para cada sistema crítico:

# Ejemplo: Objetivos de recuperación por nivel de servicio
tiers:
  - name: tier_1_critico
    examples: [payment-processing, user-authentication]
    rto: "5 minutos"
    rpo: "0 minutos"
    strategy: "activo-activo"
  - name: tier_2_importante
    examples: [reporting, analytics]
    rto: "4 horas"
    rpo: "1 hora"
    strategy: "warm-standby"
  - name: tier_3_estandar
    examples: [internal-tools, staging]
    rto: "24 horas"
    rpo: "24 horas"
    strategy: "backup-restore"

2. Mapear Dependencias y Rutas Críticas

Entiende qué debe recuperarse y en qué orden:

# Ejemplo: Grafo de dependencias de servicios para orden de recuperación
# La recuperación debe suceder en orden de dependencias:
# 1. DNS / CDN
# 2. Balanceadores / API gateways
# 3. Bases de datos (primaria primero)
# 4. Capas de caché
# 5. Servicios de aplicación
# 6. Workers en segundo plano
# 7. Analytics / jobs por lotes

Checklist de Mapeo de Dependencias

• Identificar puntos únicos de falla
• Mapear topologías de replicación de bases de datos
• Documentar dependencias de APIs externas
• Anotar servicios críticos de terceros
• Verificar que sistemas de backup sean independientes del primario

3. Diseñar Estrategia de Backup

Coincidir frecuencia de backup y retención con requerimientos de RPO:

Tipo de Datos	Frecuencia de Backup	Retención	Almacenamiento
Base de datos transaccional	Continuo o por hora	30 días + anual	Región cruzada + frío
Archivos/almacenamiento de objetos	Sincronización diaria	90 días	Región cruzada
Configuración/IaC	Cada cambio (Git)	Para siempre	Git + almacén de artefactos
Logs	Streaming en tiempo real	30-90 días	Hot + frío

# Ejemplo: Estrategia de backup PostgreSQL
# Archivado continuo (WAL) para recuperación point-in-time
cat <<EOF >> postgresql.conf
archive_mode = on
archive_command = 'aws s3 cp %p s3://my-backups/wal/%f'
wal_level = replica
EOF

# Backup base diario
pg_basebackup -D /backups/$(date +%Y%m%d) -Ft -z -P

4. Implementar Arquitectura Multi-Región

Diseñar para falla regional desde el inicio:

# Ejemplo: Kubernetes activo-pasivo multi-región
# Región primaria: us-east-1
# Región secundaria: us-west-2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  template:
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app: api-service
                topologyKey: topology.kubernetes.io/zone

Patrones Multi-Región

• Réplicas de lectura: Región primaria escribe; regiones secundarias leen réplicas
• Activo-pasivo: Primaria activa; secundaria en standby (pilot light o warm)
• Activo-activo: Ambas regiones sirven tráfico (requiere sincronización de datos)
• Basado en celdas: Arquitectura sharded con celdas en múltiples regiones

5. Crear Runbooks de Recuperación

Documentar procedimientos de recuperación paso a paso:

# Runbook: Failover de Base de Datos a Región Secundaria

## Disparador
- El health check de base de datos en la región primaria falla durante >2 minutos
- La alerta automática dispara: `database-primary-down`

## Pasos

1. **Verificar interrupción** (1 min)
   - Revisar dashboard de monitoreo
   - Confirmar problema a nivel de región (no instancia aislada)

2. **Iniciar failover** (2 min)
   - Ejecutar: `kubectl exec failover-script -- promote-replica`
   - Verificar: nueva primaria acepta escrituras

3. **Actualizar DNS** (2 min)
   - Cambiar CNAME de base de datos a región secundaria
   - TTL: 60 segundos (pre-configurado)

4. **Verificar salud de aplicación** (3 min)
   - Revisar tasas de error de aplicación
   - Verificar flujos críticos de usuarios

5. **Comunicar** (5 min)
   - Actualizar página de estado
   - Notificar a las partes interesadas

## Rollback
- Cuando la primaria se recupera, planificar failback durante ventana de mantenimiento
- Validar consistencia de datos antes de failback

Cuando los runbooks ya existen, la plantilla de plan de recuperación ante desastres los empaqueta con los objetivos RTO/RPO, el directorio de contactos y el calendario de pruebas en un documento que todo el equipo puede aprobar.

6. Probar Recuperación Regularmente

Un plan de DR que nadie ha ejecutado es un documento, no un plan:

Tipo de Prueba	Frecuencia	Alcance
Ejercicio de mesa	Trimestral	Caminar runbooks sin ejecutar
Prueba de restauración de backup	Mensual	Restaurar base de datos desde backup para verificar integridad
Drill de failover	Trimestral	Promover réplica, actualizar DNS, verificar servicio
Ingeniería del caos	Mensual	Inyectar fallas (ej. terminar base de datos primaria)
Simulación completa de DR	Anual	Simular falla completa de región y recuperación

# Ejemplo: Verificación automatizada de integridad de backup
import subprocess

def test_backup_restore():
    latest_backup = get_latest_backup()
    temp_instance = create_temp_database()
    
    restore_result = subprocess.run([
        'pg_restore',
        '--dbname', temp_instance.connection_string,
        latest_backup.path
    ], capture_output=True)
    
    if restore_result.returncode != 0:
        alert_oncall("Prueba de restauración de backup falló!")
        return False
    
    # Verificar que conteos de filas coincidan con valores esperados
    rows = temp_instance.query("SELECT count(*) FROM critical_table")
    assert rows[0][0] > 0, "Base de datos restaurada parece vacía"
    
    cleanup(temp_instance)
    return True

Lo que funciona

• Automatiza donde sea posible. El failover manual a las 3 AM es propenso a errores.
• Mantén los runbooks simples. Un desconocido de guardia a las 3 AM debería poder ejecutarlos.
• Prueba backups restaurándolos. Un backup que no puedes restaurar no es un backup.
• Monitorea lag de replicación. Si el lag excede el RPO, alerta inmediatamente.
• Documenta suposiciones. ¿Qué pasa si DNS está caído? ¿Qué pasa si el autor del runbook no está disponible?
• Separa infraestructura de DR. Los sistemas de DR no deberían depender de recursos de la región primaria.

Errores comunes

• Backups no probados. Muchas organizaciones descubren backups corruptos solo durante un desastre real.
• Sobre-ingeniería para sistemas de bajo nivel. Coincidir estrategia de DR con criticidad de negocio.
• Olvidar consistencia de datos. La replicación asíncrona puede perder transacciones durante failover.
• Ignorar el mantenimiento de runbooks. Un runbook que referencia herramientas retiradas hace una mala noche peor.
• Sin plan de comunicación. Cuando todo arde, nadie quiere escribir actualizaciones de estado; prográmalas igualmente.

Variantes

• DR cloud-native: servicios gestionados con replicación integrada (RDS Multi-AZ, Azure Site Recovery, réplicas de Cloud SQL).
• DR on-premise: copias off-site en cinta, sitios warm y tiempos de adquisición de hardware.
• DR híbrido: DR basada en cloud para cargas on-premise (pilot light inverso).

Cuándo NO invertir en DR

• Una herramienta interna con usuarios tolerantes. Si una wiki puede estar caída un día, backup-y-restaurar basta. El activo-activo quemaría presupuesto para nada.
• Servicios sin estado detrás de una cola. Los workers que consumen de una cola durable se recuperan solos cuando la cola vuelve; rara vez necesitan un runbook de failover propio.
• Prototipos previos al producto. Planificar DR antes del product-market fit optimiza para un desastre que quizá nunca importe. Un backup nocturno más una nota de restauración de una página cubre el caso.
• Cuando el riesgo real está en otra parte. Si tus últimas tres caídas fueron deploys malos, arregla primero el pipeline de deploy. DR no protege contra incidentes autoinfligidos; un blue-green deployment o un rollback por feature flags sí.

Ejemplo práctico: plataforma de pagos, una región caída

Un equipo de pagos corre en AWS con us-east-1 como región primaria y us-west-2 en warm standby. Los servicios de nivel 1 (procesamiento de pagos, auth) tienen RTO 5 min / RPO 0 mediante una réplica síncrona; el nivel 2 (reporting) tiene RTO 4 h con backup-y-restaurar.

A las 14:32, todos los health checks de la región primaria se ponen en rojo. El ingeniero de guardia abre el runbook de failover de base de datos: confirma que es un problema regional, promueve la réplica de us-west-2 (2 min), cambia el CNAME (TTL 60 s), verifica las tasas de error del flujo de pago y publica una actualización de estado. Tiempo de inactividad total: 11 minutos; dentro del RTO de 5 solo porque la alerta disparó a las 14:36 — el hueco entre el fallo y su detección también descuenta del RTO.

La lección del postmortem: su último simulacro fue un ejercicio de mesa y nadie había ejecutado promote-replica en seis meses. Pasaron los drills de failover a trimestrales con ejecución real, que es lo que el plan de pruebas formaliza.

Ver también

• AWS Whitepaper: Disaster Recovery of Workloads on AWS: la taxonomía canónica backup / pilot light / warm standby / activo-activo que sigue esta guía.
• Google SRE Workbook: Disaster Response: cómo estructura Google la respuesta a incidentes y desastres.
• Google SRE Book: Testing for Reliability: el argumento de los simulacros sobre los documentos.
• Plantilla de plan de recuperación ante desastres: empaqueta tu estrategia en un documento que las partes interesadas pueden aprobar.
• Plantilla de prueba de verificación de backups: automatiza las pruebas de restauración que recomienda esta guía.
• Recursos ejecutables del companion: el script de backup, el runbook, el YAML de niveles y la verificación de restauración de esta guía, listos para adaptar.

Conclusión

La recuperación ante desastres es un seguro para tu infraestructura. Fíjate objetivos que puedas pagar, elige la estrategia que les haga juego, escribe el runbook y luego ejecútalo de verdad. El momento de descubrir un problema en tu plan de DR es durante un simulacro, no durante un desastre real.