3 min de lectura
En resumen
- El RTO (objetivo de tiempo de recuperación) y el RPO (objetivo de punto de recuperación) determinan el diseño de la recuperación ante desastres (DR).
- La arquitectura multi-región activa-activa ofrece un RTO inferior a 1 minuto, pero cuesta entre dos y tres veces más.
- Las estrategias «Pilot Light» y «Warm Standby» ofrecen DR rentable con un RTO de 10 a 60 minutos.
- Infrastructure as Code permite crear entornos de DR reproducibles y sometibles a pruebas.
- Las pruebas periódicas de DR son obligatorias: el 40 % de las empresas que no las realizan fracasan en un escenario real.
La cuestión no es si una región en la nube fallará, sino cuándo lo hará. AWS us-east-1, Azure South Central y GCP europe-west1 han sufrido interrupciones significativas en los últimos años. Las empresas sin un plan probado de recuperación ante desastres se enfrentan entonces a una pregunta existencial: ¿con qué rapidez podremos volver a estar operativas – y cuántos datos habremos perdido?
RTO y RPO: las dos métricas que lo determinan todo
Objetivo de tiempo de recuperación (RTO) responde a esta pregunta: ¿cuál es el tiempo máximo aceptable de inactividad? Un RTO de 4 horas significa que el servicio debe restablecerse completamente dentro de las 4 horas siguientes al fallo.
Objetivo de punto de recuperación (RPO) responde a esta otra: ¿qué volumen de pérdida de datos es aceptable? Un RPO de 1 hora implica que, como máximo, se pueden perder los datos generados durante la última hora.
Ambas métricas definen el diseño de la recuperación ante desastres y su costo. Un RTO de cero y un RPO de cero exigen una arquitectura multi-región activa-activa – la opción más cara – , mientras que un RTO de 24 horas y un RPO de 24 horas pueden cubrirse con copias de seguridad diarias – la más económica – . El arte consiste en encontrar el equilibrio justo entre las necesidades del negocio y el presupuesto disponible.
Las cuatro estrategias de DR en la nube
Copia de seguridad y restauración: Copias periódicas almacenadas en otra región. En caso de desastre: se despliega la infraestructura y se restauran los datos. RTO: de 4 a 24 horas. RPO: depende de la frecuencia de las copias. Coste: mínimo (solo almacenamiento). Adecuada para cargas de trabajo no críticas.
Pilot Light: Una infraestructura mínima (réplicas de bases de datos, DNS) permanece activa permanentemente en la región de DR. En caso de desastre: se escalan los recursos de cómputo y se redirige el tráfico. RTO: de 30 a 60 minutos. RPO: minutos (gracias a la replicación). Coste: del 10 al 20 % de los costes de producción.
Warm Standby: Una versión escalada de la producción opera en la región de DR con capacidad reducida. En caso de desastre: se escala verticalmente y se redirige el tráfico. RTO: de 10 a 30 minutos. RPO: segundos. Coste: del 30 al 50 % de los costes de producción.
Multi-región activa-activa: Capacidad total en ambas regiones, con tráfico distribuido entre ellas. La caída de una región se compensa automáticamente. RTO: menos de 1 minuto. RPO: cero. Coste: del 200 al 300 % (más complejidad). Ideal para servicios críticos para el negocio y cercanos al cliente.
Infrastructure as Code como impulsor de la DR
Los planes de DR basados en procedimientos manuales suelen fracasar en situaciones reales debido al estrés, la presión de tiempo y la falta de credenciales accesibles. Infrastructure as Code (Terraform, CloudFormation, Pulumi) convierte los entornos de DR en declarativos y reproducibles.
El patrón habitual es describir por completo la infraestructura de producción mediante código. En caso de desastre, ese mismo código se ejecuta en la región de destino, ajustando únicamente las variables específicas de la región. Lo que manualmente requeriría horas, con IaC se logra en minutos. Y además es verificable: las simulacros de DR se llevan a cabo periódicamente para asegurar que el código funciona correctamente.
Replicación de datos: síncrona frente a asíncrona
Replicación síncrona escribe los datos simultáneamente en ambas regiones. RPO: cero (sin pérdida de datos). Su inconveniente: aumenta la latencia, ya que cada escritura debe esperar la confirmación desde la región de DR. Solo resulta viable entre regiones separadas por menos de 50 ms de latencia.
Replicación asíncrona escribe primero localmente y replica después, con cierto retraso. RPO: desde segundos hasta minutos (según el retardo de replicación). Su ventaja: no afecta la latencia de la producción. Es el estándar para DR entre regiones.
Servicios gestionados como Aurora Global Database, Cosmos DB y Cloud Spanner ofrecen replicación multi-región con niveles de coherencia configurables, eliminando la necesidad de gestionar infraestructuras de replicación propias.
Pruebas de DR: el factor de éxito subestimado
Un plan de DR que no se ha probado no es un plan: es una mera esperanza. Estudios indican que el 40 % de las empresas que nunca han probado su plan de DR fracasan en un escenario real por problemas imprevistos: credenciales caducadas, puntos finales de API modificados, formatos de datos incompatibles… Todos ellos problemas que solo salen a la luz mediante pruebas rigurosas.
Mejor práctica: simulacros trimestrales de DR en los que la región de respaldo asuma efectivamente el tráfico. Netflix marcó un precedente con su «Ingeniería del caos» (Chaos Monkey, simulación de interrupciones regionales), demostrando cómo garantizar continuamente la resistencia a fallos. Los servicios administrados AWS Fault Injection Service y Azure Chaos Studio ofrecen soluciones de ingeniería del caos listas para usar.
Preguntas frecuentes
¿Cuánto cuesta la recuperación ante desastres en la nube?
Depende de la estrategia elegida: copia de seguridad y restauración solo requiere almacenamiento (unos pocos euros/mes por TB). Pilot Light representa del 10 al 20 % de los costes de producción. Warm Standby, del 30 al 50 %. Active-Active, del 200 al 300 %. Para la mayoría de las pymes, Pilot Light representa el punto óptimo entre coste y disponibilidad.
¿Con qué frecuencia se deben realizar pruebas de DR?
Como mínimo, cada trimestre. Para sistemas críticos, mensualmente. Cada prueba debe documentarse exhaustivamente: qué funcionó, qué falló y qué acciones correctivas son necesarias. Las pruebas automatizadas de DR (mediante Terraform y CI/CD) permiten realizarlas con mayor frecuencia sin incrementar la carga manual.
¿Es suficiente una copia de seguridad como estrategia de DR?
Sí, para sistemas no críticos. Pero para cualquier sistema que requiera un RTO inferior a 4 horas, las copias de seguridad no bastan: el proceso de restauración lleva demasiado tiempo. Restaurar bases de datos de varios terabytes puede tardar horas. En esos casos, Pilot Light o Warm Standby son opciones mucho más adecuadas.
¿Qué ocurre en caso de un fallo multi-región?
Los fallos multi-región en un único proveedor son extremadamente raros, aunque posibles (por ejemplo, fallos de DNS o errores globales en IAM). Para alcanzar la máxima resiliencia, algunas empresas adoptan DR multi-nube: producción en AWS y DR en Azure, o viceversa. La complejidad es considerable, pero justificable para infraestructuras críticas.
¿Cómo planifico la DR para cargas de trabajo Kubernetes?
Velero es el estándar para DR en Kubernetes: respalda el estado del clúster y los volúmenes persistentes, y permite restaurarlos en otra región o en otro clúster. Para cargas de trabajo sin estado, GitOps (ArgoCD) suele ser suficiente: el estado del clúster está definido en un repositorio Git y puede desplegarse en cualquier momento en un nuevo clúster.
Fuente de imagen: Pexels / Jakub Zerdzicki
