Disaster recovery en cloud: plan, prueba y automatiza

El plan que nadie prueba

La mayoria de las empresas tienen un plan de disaster recovery. Pocas lo han probado. Menos aun lo han probado en los ultimos 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 perdida de datos o interrupcion significativa en los ultimos dos anos. De esas, el 40% descubrio durante el incidente que su plan de recuperacion tenia lagunas criticas. Un plan no probado es una hipotesis, no una garantia. 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, distribucion geografica, automatizacion nativa), pero tambien trampas. La facilidad de provisionar recursos crea una falsa sensacion de seguridad. “Si pasa algo, levantamos todo en otra region.” Eso suena bien hasta que descubres que tu base de datos tiene 3 TB, la replicacion cross-region no esta configurada, y “levantar todo” tarda 14 horas.

RTO y RPO: los dos numeros que importan

Antes de disenar cualquier estrategia, hay que cuantificar dos parametros.

RTO (Recovery Time Objective): cuanto tiempo puede estar tu servicio caido antes de que el impacto en el negocio sea inaceptable. No es una pregunta tecnica. 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): cuantos datos puedes permitirte perder. Si tu RPO es 1 hora, necesitas backups o replicacion que garanticen que nunca perderas mas de 1 hora de datos. Si tu RPO es cero, necesitas replicacion sincrona. Y la replicacion sincrona tiene costes e implicaciones de latencia que hay que entender antes de comprometerse.

La trampa comun 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 practica, tu RTO real es 2 horas independientemente de lo que diga el documento.

La conversacion productiva con la direccion es: “cual 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 decision obvia. Si la respuesta es 200 euros/hora, la justificacion cambia.

Tres niveles de DR y sus costes

Hot standby

Un entorno completo y funcional en una segunda region, recibiendo datos en tiempo real o casi real. Si la region primaria cae, el trafico se redirige al standby. El RTO es de minutos. El RPO puede ser de segundos con replicacion sincrona, o de minutos con replicacion asincrona.

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 region, 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 criticos 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 region con la infraestructura base desplegada pero escalada al minimo. Los datos se replican de forma continua. En caso de desastre, se escala la infraestructura (mas instancias, mas capacidad) antes de redirigir el trafico. El RTO es de 15-60 minutos dependiendo de cuanto 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 replicacion es continua. El compute es minimo hasta que se activa.

Justificado para: la mayoria de aplicaciones empresariales, SaaS con SLAs de 99.9%, sistemas de gestion de operaciones. Es el punto dulce entre coste y tiempo de recuperacion.

Cold standby (pilot light)

Solo los datos se replican a una segunda region. 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 trafico. 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 activacion.

Justificado para: sistemas internos, entornos de desarrollo, aplicaciones con tolerancia a downtime de horas. Y como complemento de un warm standby para datos historicos que no necesitan recuperacion inmediata.

Backups: la base olvidada

Los backups son la forma mas basica y mas subestimada de disaster recovery. Tres errores que vemos repetidamente:

No verificar la restauracion. Un backup que no se puede restaurar no es un backup. Es un archivo que ocupa espacio. El test minimo 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 ultimo backup a un entorno efimero, ejecuta validaciones basicas, y reporta el resultado.

No proteger contra eliminacion accidental. Los backups almacenados en la misma cuenta y region que la infraestructura primaria son vulnerables a eliminacion accidental (o maliciosa). Un terraform destroy erroneo o un ransomware pueden borrar produccion y backups simultaneamente. Los backups deben estar en una cuenta separada con politicas de inmutabilidad. AWS S3 Object Lock y Azure Immutable Blob Storage proporcionan esta garantia.

No calcular el tiempo de restauracion. 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 restauracion 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 que hacer, y si lo hace sin errores bajo presion a las 3 de la manana. Tres condiciones que fallan con una frecuencia incomoda.

El failover automatizado elimina el factor humano del camino critico. La implementacion tipica 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 propagacion es rapida. Route53 de AWS ofrece failover routing policies nativas. Cloudflare permite logica similar con load balancing.

Failover de base de datos. Para RDS, el failover Multi-AZ es automatico y tarda entre 60 y 120 segundos. Para bases de datos autogestionadas, la promocion de una replica a primaria requiere scripting (pg_promote en PostgreSQL, STOP SLAVE + RESET SLAVE en MySQL) y verificacion.

El failover automatizado sin failback automatizado crea un problema diferente: una vez que la region primaria se recupera, hay que volver a sincronizar los datos y revertir el trafico. Este proceso (failback) suele ser mas 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: Verificacion automatica de restauracion de backups. Un script que restaura, valida y destruye.
• Trimestral: Failover controlado al entorno secundario durante horario de bajo trafico. Todo el equipo observa y documenta.
• Semestral: Simulacion de desastre completo. Se “destruye” el entorno primario (sin destruirlo realmente: se corta el trafico) y se mide el RTO real.

Cada test produce un informe con: tiempo real de recuperacion 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 practica continua. El mejor momento para descubrir que tu plan no funciona es durante un test programado, no durante un desastre real.