¿Qué es Alta Disponibilidad y qué es Recuperación ante Desastres?
Cuando hablamos de que un sistema “siempre esté disponible”, en realidad estamos hablando de dos cosas distintas dependiendo de qué tan grave sea el problema.
Alta Disponibilidad (HA) es lo que pasa cuando algo falla de forma cotidiana: un servicio que se cae, una conexión que se pierde, un servidor que se reinicia. El sistema debe recuperarse solo y rápido, sin que el usuario lo note.
Recuperación ante Desastres (DR) es lo que pasa cuando el fallo es catastrófico: el disco se quema, alguien borra una tabla en producción, el servidor físico muere. Aquí la recuperación puede tardar más y puede requerir intervención manual, pero debe estar planificada con anticipación.
En resumen: HA es para los problemas del día a día. DR es para las situaciones que esperamos que nunca pasen, pero para las que igual hay que estar preparados.
¿Cómo se mide si la estrategia funciona?
Antes de definir cualquier estrategia hay que responder dos preguntas concretas:
RPO — Recovery Point Objective: ¿Cuántos datos podemos perder? Si todo se cae ahora, ¿hasta qué punto en el tiempo podemos retroceder sin que sea un problema grave?
RTO — Recovery Time Objective: ¿Cuánto tiempo podemos estar caídos? ¿Cuánto tiempo puede pasar desde el fallo hasta que el sistema vuelve a funcionar?
Para FutbolTrack definimos estos valores:
| Métrica | Valor | Justificación |
|---|---|---|
| RTO | 4 horas | Una academia opera en franjas de mañana y tarde. Tener el sistema caído más de 4 horas obliga a volver al papel y reingresar todo después, lo que consideramos el límite máximo tolerable |
| RPO | 15 minutos | Una sesión dura entre 90 y 120 minutos. Perder más de 15 minutos de asistencia o estadísticas tomadas en tiempo real significa perder un bloque completo de ejercicios |
Estos dos valores guían todas las decisiones de backup y disponibilidad que se describen a continuación.
Estrategia HA — Backend Flask
El backend es una API REST en Flask. Si corre en un solo proceso y ese proceso se cae, toda la aplicación queda inaccesible.
La solución es correr mínimo 2 instancias de Flask detrás de un load balancer como nginx. Si una instancia falla, el load balancer redirige todo el tráfico a la otra automáticamente.
Esto funciona bien en FutbolTrack porque la autenticación usa JWT, que es stateless — el token vive en el cliente, no en el servidor. Cambiar de instancia no rompe la sesión del entrenador.
Estrategia HA — MySQL
MySQL por defecto corre en un solo servidor. Si ese servidor falla, no hay base de datos.
La solución es configurar replicación primario → réplica:
- Todas las escrituras van al primario (crear entrenamientos, registrar asistencia, etc.)
- Las lecturas de reportes pueden ir a la réplica para no sobrecargar el primario
- Si el primario falla, la réplica se promueve manualmente o con una herramienta como MHA
Importante: la replicación no es un backup. Si alguien borra datos en el primario, esa eliminación también se replica. Para eso están los backups.
Estrategia HA — MongoDB
MongoDB tiene failover automático incorporado a través de su arquitectura de Replica Set.
La configuración es de 3 nodos: 1 primario y 2 secundarios. Si el primario pierde conexión, los dos secundarios hacen una elección automática en menos de 10 segundos y uno se convierte en el nuevo primario. La aplicación reconecta sola.
Esto protege las tres colecciones de FutbolTrack:
planes_sesionestadisticas_jugadorobservaciones_sesion
Estrategia DR — Desastres totales
Cuando el desastre ya ocurrió y no hay nada que recuperar en caliente, entra el plan de DR. Los tres pilares son:
1. Backups en ubicación separada Los backups nunca deben vivir en el mismo servidor que la base de datos. Si el servidor muere, el backup muere con él. Se almacenan en un bucket externo o servidor separado geográficamente.
2. Runbook documentado Un runbook es un documento con los pasos exactos para levantar el sistema desde cero. No sirve de nada tener backups si nadie sabe cómo restaurarlos bajo presión.
3. Pruebas de restauración periódicas Un backup que nunca se ha probado es un backup que podría no funcionar. Hay que restaurarlo en un servidor de pruebas periódicamente para verificar que todo está correcto.
Tipos de backup — ¿cuál es cuál?
Antes de ver la estrategia concreta hay que entender los tres tipos:
Backup completo: copia todo. Es el más pesado pero el más simple de restaurar.
Backup diferencial: copia solo lo que cambió desde el último completo. Para restaurar necesitas el último completo más el último diferencial.
Backup incremental: copia solo lo que cambió desde el último backup de cualquier tipo. Es el más liviano pero el más complejo de restaurar porque hay que encadenar varios archivos.