main content

< Volver a blog sobre aplicaciones móviles

Disaster Recovery y Alta Disponibilidad para Apps Web

Cómo diseñar una estrategia de disaster recovery y alta disponibilidad para tu aplicación web a medida

Cuando una empresa invierte en una aplicación web a medida, rara vez se hace la pregunta incómoda: ¿qué pasa si todo se cae? Un fallo de hardware, un error humano en producción, un ransomware o una caída del centro de datos pueden convertir una herramienta crítica de negocio en una pantalla en blanco. Y el coste no es abstracto: según Gartner, una hora de downtime le cuesta a una empresa mediana unos 300.000 dólares de media.

En este artículo te explicamos, paso a paso, cómo montar una estrategia sólida de disaster recovery (DR) y alta disponibilidad (HA) para aplicaciones web a medida. Con arquitecturas concretas, herramientas reales y cifras actuales de los principales proveedores cloud.

Disaster recovery vs. alta disponibilidad: no son lo mismo

Antes de ponerse a diseñar nada, conviene aclarar dos conceptos que se confunden constantemente.

Concepto	Objetivo	Alcance	Ejemplo
Alta disponibilidad (HA)	Minimizar el tiempo de inactividad durante fallos operativos	Componentes individuales o zonas dentro de una región	Dos servidores web detrás de un balanceador de carga
Disaster recovery (DR)	Recuperar el sistema completo tras un desastre mayor	Regiones geográficas o incluso proveedores distintos	Réplica de toda la infraestructura en otra región de AWS

La alta disponibilidad te protege de los sustos del día a día. El disaster recovery entra en juego cuando la HA ya no es suficiente: incendios en centros de datos (como el de OVH en Estrasburgo en 2021), desastres naturales o fallos regionales completos.

Una estrategia completa necesita las dos capas. HA para el día a día, DR para lo impensable.

RPO y RTO: las dos métricas que definen tu estrategia

Toda estrategia de continuidad se construye sobre dos métricas fundamentales:

RPO (Recovery Point Objective)

Es la cantidad máxima de datos que tu negocio puede permitirse perder. Si tu RPO es de 1 hora, necesitas backups o replicación al menos cada 60 minutos. Si es de 0, necesitas replicación síncrona en tiempo real.

RTO (Recovery Time Objective)

Es el tiempo máximo que puede tardar tu aplicación en volver a estar operativa tras un desastre. Si tu RTO es de 15 minutos, necesitas failover automatizado. Si es de 24 horas, puedes restaurar desde backups manualmente.

Cómo determinar tus RPO y RTO

Lo importante aquí no es lo técnico, sino lo de negocio. Hazte estas preguntas:

¿Cuánto factura tu aplicación por hora? Un e-commerce que factura 5.000 EUR/hora tiene un RTO muy distinto al de una herramienta interna de reporting.
¿Qué datos se generan entre backups? Si tus usuarios suben documentos críticos cada 10 minutos, un RPO de 24 horas es inaceptable.
¿Hay obligaciones contractuales de SLA? Muchos contratos B2B exigen disponibilidades del 99,9 % (menos de 8,7 horas de downtime al año).

Nivel	RPO	RTO	Coste relativo	Caso de uso típico
Básico	24 horas	24-48 horas	Bajo	Herramientas internas no críticas
Estándar	1-4 horas	1-4 horas	Medio	Aplicaciones B2B con horario comercial
Avanzado	Minutos	15-30 minutos	Alto	E-commerce, plataformas SaaS
Crítico	0 (cero pérdida)	Segundos	Muy alto	Fintech, salud, sistemas transaccionales

Arquitecturas de alta disponibilidad y disaster recovery

Activo-pasivo

Aquí tienes un entorno primario que gestiona todo el tráfico y un entorno secundario en standby que solo se activa cuando el primario falla.

Ventajas:

Coste reducido: el entorno pasivo puede usar instancias más pequeñas o incluso estar apagado.
Configuración más sencilla.

Desventajas:

El failover no es instantáneo (típicamente entre 5 y 30 minutos).
El entorno pasivo puede tener datos ligeramente desactualizados si la replicación es asíncrona.

Coste estimado en AWS: Si tu entorno primario cuesta 800 EUR/mes, el pasivo puede salirte entre 200 y 400 EUR/mes (instancias detenidas + almacenamiento replicado).

Activo-activo

Ambos entornos procesan tráfico a la vez. Si uno falla, el otro absorbe toda la carga sin interrupción perceptible.

Ventajas:

Failover prácticamente instantáneo (segundos).
Mejor rendimiento global al distribuir carga geográficamente.
RPO cercano a cero con replicación síncrona.

Desventajas:

Coste significativamente mayor (prácticamente el doble).
Complejidad técnica elevada: gestión de conflictos de escritura, consistencia eventual, routing inteligente.

Coste estimado en AWS: Si tu entorno primario cuesta 800 EUR/mes, el activo-activo rondará los 1.400-1.800 EUR/mes en total.

Pilot Light

Una variante más económica del activo-pasivo: solo mantienes activos los componentes mínimos esenciales (típicamente la base de datos replicada) y el resto de la infraestructura se levanta bajo demanda.

Coste estimado: Entre un 15 % y un 25 % del coste del entorno primario.

Replicación de bases de datos: el corazón de toda estrategia

La base de datos suele ser el componente más crítico y el más difícil de replicar correctamente.

Replicación síncrona vs. asíncrona

Tipo	Cómo funciona	RPO	Impacto en rendimiento	Distancia viable
Síncrona	La escritura no se confirma hasta que ambas réplicas la registran	0	Alto (latencia adicional de 2-10 ms)	Misma región (< 100 km)
Asíncrona	La escritura se confirma en el primario y se replica después	Segundos a minutos	Bajo	Multi-región, global

Soluciones concretas por motor de base de datos

PostgreSQL: Streaming replication nativa + pg_basebackup para backups. Para multi-región, herramientas como Patroni o Citus.
MySQL/MariaDB: Group Replication para clusters síncronos. Para DR, réplica asíncrona clásica master-slave.
MongoDB: Replica Sets con miembros en distintas zonas/regiones. Failover automático integrado.
Servicios gestionados: AWS RDS Multi-AZ (failover automático en menos de 60 segundos), Google Cloud SQL con HA, Azure Database con geo-replicación.

Arquitectura multi-AZ y multi-región

Multi-AZ (multi zona de disponibilidad)

Es el mínimo exigible para cualquier aplicación en producción. Cada proveedor cloud divide sus regiones en zonas de disponibilidad (AZ), que son centros de datos independientes con energía, refrigeración y red propias.

Desplegar en múltiples AZ te protege contra fallos de un centro de datos individual. Es la capa de HA básica y su coste adicional es mínimo (generalmente entre un 10 % y un 20 % más por la redundancia de instancias y el tráfico inter-AZ).

Multi-región

Protege contra desastres que afecten a una región entera. Es extremadamente raro, pero ocurre. Implica replicar toda la infraestructura en una región geográficamente separada.

Consideraciones para empresas españolas:

Región primaria: eu-west-1 (Irlanda) o eu-south-2 (España, disponible en AWS desde 2022).
Región secundaria DR: eu-central-1 (Frankfurt) o eu-west-3 (París).
Latencia inter-región típica: 15-30 ms entre regiones europeas, imperceptible para la mayoría de aplicaciones.

Failover automatizado: cuando cada segundo cuenta

Un plan de DR que dependa de que alguien conteste el teléfono a las 3 de la mañana no es un plan fiable. El failover automatizado es imprescindible para RTOs inferiores a 30 minutos.

Componentes clave

Health checks continuos: Verificar cada 10-30 segundos que la aplicación responde correctamente. No solo que el servidor está encendido, sino que devuelve respuestas válidas.
DNS failover: Servicios como AWS Route 53, Cloudflare o Google Cloud DNS pueden redirigir el tráfico automáticamente al entorno secundario cuando los health checks fallan.
Orquestación de failover: Scripts o herramientas (AWS Lambda, Terraform, Ansible) que levanten automáticamente los componentes del entorno secundario si estaban en standby.

Ejemplo de flujo automatizado: El health check falla 3 veces consecutivas en 90 segundos, se activa la alarma en CloudWatch, Lambda ejecuta el script de failover que promociona la réplica de base de datos a primaria, actualiza el DNS (TTL de 60 s), y notifica al equipo por Slack. Tiempo total: entre 3 y 5 minutos.

Backups y snapshots: tu última línea de defensa

Aunque tengas replicación en tiempo real, los backups siguen siendo imprescindibles. Y es que la replicación también propaga los errores: si alguien ejecuta un DELETE FROM usuarios sin WHERE, la réplica lo ejecutará igualmente.

Estrategia de backups recomendada

Tipo	Frecuencia	Retención	Dónde
Snapshots de base de datos	Cada 6 horas	7 días	Misma región
Backup completo diario	Cada 24 horas	30 días	Región secundaria
Backup semanal	Cada 7 días	90 días	Región secundaria + almacenamiento frío
Backup mensual	Cada 30 días	1 año	Almacenamiento frío (Glacier, Coldline)

Costes reales de almacenamiento de backups

Para una base de datos de 50 GB con la estrategia anterior:

AWS S3 Standard + Glacier: Aproximadamente 15-25 EUR/mes.
Google Cloud Storage + Coldline: Aproximadamente 12-20 EUR/mes.
Azure Blob Storage + Archive: Aproximadamente 14-22 EUR/mes.

Son cifras muy asumibles comparadas con el coste de perder esos datos.

Testing de planes de DR: chaos engineering

Un plan de disaster recovery que no se prueba regularmente no es un plan, es una esperanza. El chaos engineering, que Netflix popularizó con su herramienta Chaos Monkey, consiste en introducir fallos deliberados en producción (o en entornos de staging) para verificar que los mecanismos de recuperación funcionan de verdad.

Pruebas que deberías realizar periódicamente

Failover de base de datos (trimestral): Forzar la promoción de la réplica secundaria y verificar que la aplicación sigue funcionando.
Caída de una zona de disponibilidad (semestral): Simular la pérdida de una AZ completa y verificar que el tráfico se redistribuye.
Restauración completa desde backup (trimestral): Restaurar la aplicación desde cero a partir de backups y medir el tiempo real de recuperación.
Simulacro de DR completo (anual): Activar el entorno de DR completo como si la región primaria hubiera desaparecido.

Herramientas de chaos engineering

AWS Fault Injection Simulator: Integrado con el ecosistema AWS, permite simular fallos de instancias, red y servicios.
Gremlin: Plataforma comercial con interfaz visual, ideal para equipos que empiezan con chaos engineering.
Litmus (open source): Diseñado para entornos Kubernetes.

Costes reales: cuánto cuesta proteger tu aplicación

Uno de los mayores frenos para implementar DR y HA es la percepción de que es prohibitivamente caro. Veamos cifras reales para una aplicación web a medida típica.

Escenario: aplicación web con 10.000 usuarios activos

Infraestructura base (sin HA ni DR): 600-1.000 EUR/mes en cualquier cloud.

Nivel de protección	Coste adicional mensual	Protección obtenida
Multi-AZ (HA básica)	+100-200 EUR	Protección contra fallo de un centro de datos
Backups automatizados multi-región	+30-50 EUR	RPO de 6-24 horas
Pilot Light DR	+150-300 EUR	RTO de 1-2 horas, RPO de minutos
Activo-pasivo warm standby	+400-600 EUR	RTO de 15-30 minutos
Activo-activo multi-región	+800-1.200 EUR	RTO de segundos, RPO cercano a 0

Lo que recomendamos para la mayoría de PYMEs españolas: Multi-AZ + backups multi-región + pilot light. Eso supone un incremento de entre 280 y 550 EUR/mes sobre la infraestructura base. Una inversión razonable para proteger un activo digital que probablemente costó entre 30.000 y 100.000 EUR desarrollar.

Compliance y regulación española: RGPD y más

Diseñar una estrategia de DR para una empresa española no es solo una cuestión técnica. También tiene implicaciones legales que no puedes ignorar.

RGPD y localización de datos

Los backups y réplicas que contengan datos personales deben residir en países con un nivel adecuado de protección según el RGPD. En la práctica, esto significa cualquier país del Espacio Económico Europeo (EEE) o países con decisiones de adecuación (como Reino Unido, Japón o Corea del Sur).
Si tus réplicas de DR están en regiones fuera del EEE (por ejemplo, us-east-1 de AWS), necesitarás Cláusulas Contractuales Tipo (SCCs) y una evaluación de impacto de transferencia.
Consejo práctico: Mantén toda tu infraestructura de DR dentro de Europa. AWS, Google Cloud y Azure tienen suficientes regiones europeas para cubrir cualquier necesidad.

Esquema Nacional de Seguridad (ENS)

Si tu aplicación presta servicios a administraciones públicas españolas, el ENS exige medidas concretas de continuidad del servicio (categorías media y alta) que incluyen planes de contingencia documentados y probados.

Ley de Protección de Infraestructuras Críticas

Para sectores regulados (energía, transporte, finanzas, salud), hay requisitos adicionales de disponibilidad y recuperación que pueden exigir arquitecturas activo-activo y RTOs inferiores a minutos.

Checklist de implementación

Antes de dar por completa tu estrategia, revisa cada uno de estos puntos:

Fase 1: Análisis y planificación

Análisis de impacto de negocio (BIA) completado
RPO y RTO definidos por cada componente del sistema
Presupuesto de DR aprobado por dirección
Requisitos regulatorios identificados (RGPD, ENS, sectorial)

Fase 2: Infraestructura

Despliegue multi-AZ implementado para todos los componentes
Replicación de base de datos configurada y verificada
Backups automatizados con retención definida
Backups almacenados en región secundaria
Entorno de DR provisionado (pilot light, warm standby o activo-activo)

Fase 3: Automatización

Health checks configurados con umbrales definidos
Failover de DNS automatizado
Scripts de failover probados y documentados
Alertas y notificaciones configuradas (email, Slack, PagerDuty)

Fase 4: Documentación y procedimientos

Runbooks de DR documentados paso a paso
Roles y responsabilidades asignados
Contactos de emergencia actualizados
Procedimientos de comunicación a clientes definidos

Fase 5: Testing continuo

Calendario de pruebas de DR establecido
Primera prueba de failover de base de datos completada
Primera restauración completa desde backup verificada
Simulacro de DR completo planificado

Conclusión: la continuidad no es un lujo, es una necesidad

Diseñar una estrategia de disaster recovery y alta disponibilidad para tu aplicación web a medida no es un ejercicio teórico ni un capricho técnico. Es una decisión de negocio que protege la inversión en desarrollo, la confianza de tus clientes y, en muchos casos, el cumplimiento normativo.

La buena noticia: no hace falta empezar con una arquitectura activo-activo multi-región. Una implementación por fases, comenzando por multi-AZ y backups automatizados, ya proporciona un nivel de protección significativo con un coste muy contenido.

Si necesitas diseñar o revisar la estrategia de continuidad de tu aplicación web a medida, contacta con nuestro equipo para una evaluación personalizada de tus necesidades de DR y alta disponibilidad.

Contacta con nosotros