Hay una conversación que casi ningún equipo quiere tener hasta que es demasiado tarde: ¿qué pasa si mañana perdemos la región entera, la cuenta de la nube o la base de datos de producción? Tener backups no es tener un plan de recuperación ante desastres, igual que tener un extintor no es lo mismo que saber evacuar el edificio. La buena noticia es que diseñar un plan decente no exige duplicar la factura. Exige, sobre todo, decidir dos números.
RTO y RPO: los dos números que mandan
El RTO (Recovery Time Objective) es cuánto tiempo puedes permitirte estar caído: minutos, horas, un día. El RPO (Recovery Point Objective) es cuántos datos puedes permitirte perder: la última hora, el último día, absolutamente nada. Y aquí viene lo importante: no son números técnicos, son decisiones de negocio. Mi trabajo como ingeniero es ponerles precio; el del negocio, elegir cuánto está dispuesto a pagar. Un RTO de cinco minutos con RPO cero cuesta una fortuna; cuatro horas de caída y quince minutos de datos cuestan muchísimo menos. Sin esos dos números sobre la mesa, cualquier arquitectura de recuperación es humo.
Las cuatro estrategias clásicas
- Backup y restore: la más barata. Copias de seguridad bien hechas y la capacidad de reconstruir la infraestructura desde código. RTO de horas, ideal para sistemas que toleran esperar.
- Pilot light: mantienes encendido lo mínimo imprescindible en la región de respaldo (normalmente los datos, replicados de forma continua) y levantas el resto solo cuando hace falta.
- Warm standby: una copia reducida pero funcional del sistema corriendo en paralelo, lista para escalar. RTO de minutos a cambio de un coste fijo moderado.
- Activo-activo: todo corriendo en dos o más regiones a la vez, con RTO cercano a cero y factura acorde. Solo lo justifican cargas realmente críticas.
Donde los planes mueren de verdad
- Backups que nadie ha restaurado: un backup sin probar es una hipótesis, no una garantía. Hasta que no restauras, no tienes nada.
- Dependencias fuera del plan: DNS, certificados, secretos, imágenes de contenedor, el propio pipeline de despliegue… Si recuperarte depende de algo que solo vive en la región caída, no tienes plan.
- Runbooks desactualizados: el documento de recuperación escrito hace dos años describe un sistema que ya no existe. Un plan que no se ensaya, se pudre.
- El factor humano: a las tres de la mañana y con producción caída nadie improvisa bien. El plan tiene que poder ejecutarlo la persona de guardia, no solo quien lo diseñó.
Ensaya como si fuera real
Lo único que convierte un documento en un plan es ensayarlo. Los game days (simulacros programados en los que provocas fallos a propósito en un entorno controlado) son la mejor inversión en resiliencia que conozco. Y hay una versión mínima que cualquier equipo puede automatizar hoy: restaurar el último backup en un entorno efímero y lanzar una prueba de humo, cada semana y sin humanos de por medio.
# Ensayo semanal automatizado (esqueleto)
ultimo_backup="$(listar_backups | tail -n 1)"
crear_entorno_efimero
restaurar_backup "${ultimo_backup}"
ejecutar_smoke_tests && registrar_ok || alertar_al_equipo
destruir_entorno_efimeroSi ese esqueleto lleva meses en verde, tu RPO deja de ser una promesa y pasa a ser un dato medido. El día que falle, te alegrarás de haberlo descubierto un martes cualquiera y no durante el incidente.
La recuperación ante desastres no va de comprar redundancia, va de decidir cuánto vale tu tiempo de caída y diseñar en consecuencia. Dos números claros, una estrategia acorde al bolsillo y ensayos regulares valen más que cualquier arquitectura heroica sin probar. ¿Tu equipo ha ensayado alguna vez una recuperación completa o de momento es un acto de fe? Te leo en los comentarios 😊