Disaster recovery en cloud: plan, prueba y automatiza
El plan que nadie prueba
La mayoría de las empresas tienen un plan de disaster recovery. Pocas lo han probado. Menos aún lo han probado en los últimos 12 meses. Y las que lo han probado descubrieron que no funcionaba como esperaban.
Un informe de Zerto (2024) cifra que el 76% de las organizaciones han sufrido al menos un incidente de pérdida de datos o interrupción significativa en los últimos dos años. De esas, el 40% descubrio durante el incidente que su plan de recuperación tenía lagunas críticas. Un plan no probado es una hipótesis, no una garantía. Un marco de ciberseguridad robusto incluye DR como parte integral de su estrategia.
En cloud, el disaster recovery tiene ventajas estructurales sobre el modelo on-premise (elasticidad, distribución geográfica, automatización nativa), pero también trampas. La facilidad de provisionar recursos crea una falsa sensación de seguridad. “Si pasa algo, levantamos todo en otra región.” Eso suena bien hasta que descubres que tu base de datos tiene 3 TB, la replicación cross-region no está configurada, y “levantar todo” tarda 14 horas.
RTO y RPO: los dos números que importan
Antes de diseñar cualquier estrategia, hay que cuantificar dos parámetros.
RTO (Recovery Time Objective): cuánto tiempo puede estar tu servicio caído antes de que el impacto en el negocio sea inaceptable. No es una pregunta técnica. Es una pregunta de negocio. Un ecommerce con un RTO de 4 horas pierde ventas durante esas 4 horas. Un sistema interno de RRHH con un RTO de 24 horas probablemente es tolerable.
RPO (Recovery Point Objective): cuántos datos puedes permitirte perder. Si tu RPO es 1 hora, necesitas backups o replicación que garanticen que nunca perderás más de 1 hora de datos. Si tu RPO es cero, necesitas replicación síncrona. Y la replicación síncrona tiene costes e implicaciones de latencia que hay que entender antes de comprometerse.
La trampa común es definir RTO y RPO aspiracionales en lugar de realistas. Un RTO de “15 minutos” suena profesional, pero si tu proceso de recovery tarda 2 horas en la práctica, tu RTO real es 2 horas independientemente de lo que diga el documento.
La conversación productiva con la dirección es: “cuál es el coste por hora de inactividad?” Si la respuesta es 5.000 euros/hora, invertir 2.000 euros/mes en infraestructura que reduce el RTO de 8 horas a 1 hora es una decisión obvia. Si la respuesta es 200 euros/hora, la justificación cambia.
Tres niveles de DR y sus costes
Hot standby
Un entorno completo y funcional en una segunda región, recibiendo datos en tiempo real o casi real. Si la región primaria cae, el tráfico se redirige al standby. El RTO es de minutos. El RPO puede ser de segundos con replicación síncrona, o de minutos con replicación asíncrona.
El coste es alto: esencialmente pagas el doble de infraestructura de compute y almacenamiento. En AWS, un hot standby con RDS Multi-AZ, ECS/EKS en la segunda región, y Route53 para failover DNS puede costar entre un 80% y un 100% adicional sobre la infraestructura primaria.
Justificado para: ecommerce de alto volumen, plataformas financieras, sistemas críticos de salud. Cualquier servicio donde el coste de una hora de downtime supere el coste mensual del standby.
Warm standby
Un entorno reducido en la segunda región con la infraestructura base desplegada pero escalada al mínimo. Los datos se replican de forma continua. En caso de desastre, se escala la infraestructura (más instancias, más capacidad) antes de redirigir el tráfico. El RTO es de 15-60 minutos dependiendo de cuánto hay que escalar.
El coste es moderado: entre un 30% y un 50% adicional. La base de datos y el almacenamiento representan la mayor parte del coste porque la replicación es continua. El compute es mínimo hasta que se activa.
Justificado para: la mayoría de aplicaciones empresariales, SaaS con SLAs de 99.9%, sistemas de gestión de operaciones. Es el punto dulce entre coste y tiempo de recuperación.
Cold standby (pilot light)
Solo los datos se replican a una segunda región. La infraestructura de compute no existe hasta que se necesita. En caso de desastre, se provisiona la infraestructura desde cero (usando Infrastructure as Code), se conecta a los datos replicados, y se redirige el tráfico. El RTO es de horas.
El coste es bajo: solo el almacenamiento de los datos replicados y el coste de transferencia entre regiones. En AWS, el almacenamiento cross-region de un RDS snapshot de 500 GB cuesta aproximadamente 50 euros/mes. El compute es cero hasta la activación.
Justificado para: sistemas internos, entornos de desarrollo, aplicaciones con tolerancia a downtime de horas. Y como complemento de un warm standby para datos históricos que no necesitan recuperación inmediata.
Backups: la base olvidada
Los backups son la forma más básica y más subestimada de disaster recovery. Tres errores que vemos repetidamente:
No verificar la restauración. Un backup que no se puede restaurar no es un backup. Es un archivo que ocupa espacio. El test mínimo es restaurar un backup en un entorno de prueba al menos una vez al trimestre. Automatizar este test es lo ideal: un job semanal que restaura el último backup a un entorno efímero, ejecuta validaciones básicas, y reporta el resultado.
No proteger contra eliminación accidental. Los backups almacenados en la misma cuenta y región que la infraestructura primaria son vulnerables a eliminación accidental (o maliciosa). Un terraform destroy erróneo o un ransomware pueden borrar producción y backups simultáneamente. Los backups deben estar en una cuenta separada con políticas de inmutabilidad. AWS S3 Object Lock y Azure Immutable Blob Storage proporcionan esta garantía.
No calcular el tiempo de restauración. Restaurar un backup de 500 GB desde S3 a un RDS instance lleva tiempo. Hemos medido entre 45 minutos y 3 horas dependiendo del tipo de instancia y el formato del backup. Si tu RTO es 1 hora y la restauración tarda 2 horas, tu estrategia de backup no cumple tu RTO.
Failover automatizado
El failover manual funciona si hay alguien disponible, si esa persona sabe qué hacer, y si lo hace sin errores bajo presión a las 3 de la mañana. Tres condiciones que fallan con una frecuencia incómoda.
El failover automatizado elimina el factor humano del camino crítico. La implementación típica usa:
Health checks activos. Un componente externo (Route53 health checks, Cloudflare health checks, un servicio dedicado como Pingdom o UptimeRobot) verifica la disponibilidad del entorno primario. Si falla N checks consecutivos, se dispara el failover.
DNS failover. El registro DNS se actualiza para apuntar al entorno secundario. Con TTLs bajos (60 segundos), la propagación es rápida. Route53 de AWS ofrece failover routing policies nativas. Cloudflare permite lógica similar con load balancing.
Failover de base de datos. Para RDS, el failover Multi-AZ es automático y tarda entre 60 y 120 segundos. Para bases de datos autogestionadas, la promoción de una réplica a primaria requiere scripting (pg_promote en PostgreSQL, STOP SLAVE + RESET SLAVE en MySQL) y verificación.
El failover automatizado sin failback automatizado crea un problema diferente: una vez que la región primaria se recupera, hay que volver a sincronizar los datos y revertir el tráfico. Este proceso (failback) suele ser más complejo que el failover y debe estar igualmente documentado y probado.
Cadencia de testing
Un plan de DR que no se prueba se degrada con cada cambio en la infraestructura. Cada nueva tabla en la base de datos, cada nuevo microservicio, cada nueva dependencia externa puede invalidar supuestos del plan.
Nuestra cadencia recomendada:
- Mensual: Verificación automática de restauración de backups. Un script que restaura, valida y destruye.
- Trimestral: Failover controlado al entorno secundario durante horario de bajo tráfico. Todo el equipo observa y documenta.
- Semestral: Simulación de desastre completo. Se “destruye” el entorno primario (sin destruirlo realmente: se corta el tráfico) y se mide el RTO real.
Cada test produce un informe con: tiempo real de recuperación medido, incidencias encontradas, diferencias respecto al plan documentado, y acciones correctivas. Las acciones correctivas tienen fecha y responsable. Sin esto, el informe es papel mojado.
El DR no es un proyecto. Es una práctica continua. El mejor momento para descubrir que tu plan no funciona es durante un test programado, no durante un desastre real.
