¿Cómo diseñas recuperación ante desastres cloud?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

La DR en la nube se elige por nivel de servicio a partir del RTO y RPO del negocio. Copia y restauración es lo más barato y lento; piloto mantiene datos replicados y un núcleo mínimo en marcha para escalar el cómputo; standby caliente ejecuta una copia reducida que toma tráfico en minutos; activo-activo sirve desde varias regiones continuamente a costa de una consistencia de datos compleja. La replicación de datos debe cumplir el RPO, la infraestructura se define como código para construir o escalar la región de recuperación bajo demanda, DNS o balanceo global gestiona el cambio, y todo se prueba de forma aislada según calendario, porque una región de recuperación sin probar se desvía de producción.

Ejemplo

Una plataforma SaaS clasificó sus servicios: la API y la base de datos son standby caliente en una segunda región con replicación entre regiones con menos de 30 segundos de retraso y failover por comprobación de salud en Route 53, con un RTO de 15 minutos; el warehouse de informes es copia y restauración con un RTO de 24 horas. Una prueba trimestral promueve la base de datos standby, escala el clúster standby y sirve tráfico sintético; la segunda prueba atrapó un módulo de Terraform actualizado solo en la región primaria.

Errores frecuentes

• Elegir activo-activo para todo y pagar problemas de consistencia que nadie necesitaba.
• Replicar datos pero dejar la región de recuperación sin la infraestructura para usarlos.
• Probar la DR leyendo el runbook en lugar de hacer failover.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.