Backup y recuperación ante desastres (DR) en la nube

Un desastre no es solo un terremoto o un incendio en el datacenter. En la realidad empresarial moderna, los eventos que interrumpen la operación son mucho más frecuentes y mundanos: un error humano que borra una base de datos de producción, un ataque de ransomware que cifra los sistemas críticos, un fallo en una actualización de software que deja la aplicación inoperativa o un proveedor cloud que experimenta una interrupción regional. La pregunta no es si ocurrirá algo así, sino cuándo, y cuánto tardará la empresa en recuperarse.

La nube ha democratizado el acceso a capacidades de backup y recuperación ante desastres que antes estaban reservadas a grandes corporaciones con presupuestos millonarios. Un segundo datacenter de disaster recovery, que antes requería infraestructura física duplicada, ahora se puede implementar en horas con recursos cloud bajo demanda. Sin embargo, la disponibilidad de las herramientas no garantiza su uso correcto: muchas empresas tienen backups que nunca han probado, RPOs y RTOs definidos en papel pero nunca verificados, y planes de DR que nadie conoce cuando se produce el incidente real.

Este artículo ofrece un marco práctico para diseñar, implementar y mantener una estrategia de backup y disaster recovery en la nube que funcione cuando más se necesita.

Conceptos fundamentales: RPO, RTO y los niveles de disponibilidad

Antes de hablar de arquitecturas y herramientas, es imprescindible tener claridad sobre los objetivos. El Recovery Point Objective (RPO) define cuánta pérdida de datos es aceptable: si el RPO es de una hora, significa que en el peor caso perdemos hasta una hora de datos. El Recovery Time Objective (RTO) define cuánto tiempo puede estar el sistema fuera de servicio antes de que el impacto sea inaceptable para el negocio.

Estos dos parámetros son decisiones de negocio, no de IT. El responsable de IT puede proporcionar las opciones técnicas y sus costes, pero quien debe decidir el RPO y el RTO es el responsable del proceso de negocio que depende del sistema. Un RPO de cero (sin pérdida de datos) y un RTO de segundos tienen un coste muy diferente al de un RPO de veinticuatro horas y un RTO de cuatro horas. La mayoría de las empresas sobreestiman la criticidad de sus sistemas hasta que ven el coste de la protección correspondiente.

Clasificación de sistemas por criticidad

El primer paso de cualquier estrategia de DR es clasificar los sistemas según su criticidad para el negocio. Una taxonomía habitual distingue tres niveles: crítico (el negocio no puede operar sin él; RTO en minutos, RPO en segundos o minutos), importante (el impacto es significativo pero el negocio puede operar de forma degradada; RTO en horas, RPO en horas) y no crítico (el impacto es menor; RTO en días, RPO en días). Esta clasificación guía la inversión en protección y evita tratar todos los sistemas con el mismo nivel de coste.

Arquitecturas de DR en la nube: las cuatro estrategias

AWS popularizó una clasificación de cuatro estrategias de DR en la nube ordenadas por coste y capacidad de recuperación. Esta clasificación es útil como marco de referencia y es ampliamente adoptada en el sector, aunque los mismos principios aplican a Azure y GCP.

Backup and Restore

Es la estrategia más económica y la de mayor RTO y RPO. Los datos se respaldan periódicamente a almacenamiento cloud de bajo coste (S3, Azure Blob, GCS). En caso de desastre, se aprovisiona nueva infraestructura y se restauran los datos desde el backup. El RTO puede ser de varias horas o incluso días, dependiendo del volumen de datos y la velocidad de aprovisionamiento. Es adecuada para sistemas no críticos o para la capa de datos de sistemas que tienen una capa de aplicación stateless que puede re-desplegarse rápidamente.

Pilot Light

En el patrón Pilot Light, los componentes más críticos del sistema (típicamente la base de datos) están siempre activos en el entorno de DR, replicándose en tiempo real desde producción. El resto de la infraestructura (servidores de aplicación, balanceadores) está apagada o reducida al mínimo. En caso de desastre, se escala rápidamente la infraestructura de DR y se redirige el tráfico. El RTO es de decenas de minutos a pocas horas, y el RPO es cercano a cero para los datos replicados.

Warm Standby

El Warm Standby mantiene una versión reducida pero completamente funcional del sistema en la región de DR, con todos los componentes activos pero con capacidad de cómputo inferior. En producción normal puede atender una fracción del tráfico; en caso de desastre, se escala a capacidad completa. El RTO es de minutos y el RPO es mínimo. El coste es mayor que Pilot Light porque hay infraestructura activa constantemente.

Multi-Site Active-Active

En la estrategia activo-activo, el sistema opera simultáneamente en múltiples regiones o zonas, con el tráfico distribuido entre ellas. No hay un proceso de 'failover': si una región falla, el tráfico se redistribuye automáticamente entre las demás. El RTO es de segundos y el RPO es prácticamente cero. Es la estrategia más cara y compleja, adecuada solo para los sistemas más críticos del negocio.

El error más caro en DR no es elegir una estrategia de bajo coste para un sistema crítico. Es elegir una estrategia de alto coste para un sistema que no lo justifica. Una buena estrategia de DR empieza por una conversación honesta con el negocio sobre cuánto vale realmente cada hora de inactividad.

Backup en la nube: más allá de copiar archivos

El backup en la nube no es simplemente copiar datos a un bucket de S3. Una estrategia de backup completa debe contemplar la granularidad de los backups (¿cada cuánto?), la retención (¿cuánto tiempo se guardan?), la inmutabilidad (¿pueden ser borrados o cifrados por un ransomware?), el cifrado (¿están protegidos en reposo y en tránsito?) y la verificación periódica (¿funcionan realmente?).

La regla 3-2-1 sigue siendo el estándar de referencia: tres copias de los datos, en dos medios diferentes, con una copia fuera del sitio (offsite). En el contexto cloud, esto puede traducirse en: datos originales en producción, backup en otra región del mismo proveedor y copia adicional en un proveedor diferente o en cintas offsite para datos regulados. El tercer elemento —la copia fuera del entorno principal— es crucial para la protección contra ransomware, que suele intentar cifrar todos los destinos de backup accesibles desde el sistema comprometido.

Inmutabilidad: la defensa clave contra el ransomware

El ransomware ha convertido la inmutabilidad de los backups en un requisito, no en una opción. Un backup mutable puede ser cifrado o borrado por el mismo malware que cifró el sistema de producción si tiene acceso a las credenciales de la cuenta cloud. Los backups inmutables, una vez escritos, no pueden ser modificados ni eliminados durante el período de retención definido, independientemente de las credenciales con las que se intente.

AWS S3 Object Lock en modo Compliance, Azure Blob Storage con Immutable Blob Storage y GCS con Object Hold son las implementaciones nativas de inmutabilidad en cada proveedor. AWS Backup soporta bóvedas de backup con políticas de bloqueo que impiden la eliminación. Estas capacidades deben configurarse explícitamente; no están activas por defecto.

• Activa S3 Object Lock o equivalente en modo Compliance para los buckets de backup críticos.
• Separa la cuenta o suscripción de backup de la cuenta de producción: credenciales diferentes, menor radio de acción en caso de compromiso.
• Configura retenciones que cubran el período de descubrimiento del ransomware: si el cifrado puede haber comenzado hace treinta días, necesitas backups de más de treinta días atrás.
• Verifica regularmente que las políticas de inmutabilidad están activas y no han sido modificadas.
• Implementa alertas si se detectan intentos de eliminar o modificar los objetos de backup.

Herramientas de backup y DR en el ecosistema cloud

Cada proveedor cloud tiene su servicio de backup gestionado: AWS Backup, Azure Backup y Google Cloud Backup and DR. Estos servicios permiten definir políticas de backup centralizadas para múltiples tipos de recursos (instancias, bases de datos, volúmenes de almacenamiento, sistemas de archivos) desde un único panel de control.

Para entornos multi-cloud o con requisitos avanzados, existen soluciones especializadas. Veeam Backup for Public Cloud es la referencia en el mercado enterprise con soporte para AWS, Azure y GCP. Commvault Complete Data Protection ofrece gestión unificada on-premise y cloud. Rubrik y Cohesity son plataformas de protección de datos de nueva generación con capacidades avanzadas de análisis de ransomware y recuperación granular.

Para bases de datos específicas, los servicios gestionados cloud tienen capacidades de backup integradas que son el punto de partida recomendado: RDS Automated Backups y Multi-AZ en AWS, Azure SQL Automated Backups, Cloud SQL en GCP. Estas herramientas nativas son más fáciles de operar y están optimizadas para cada motor de base de datos.

Replicación de datos: la base del RPO bajo

Para alcanzar RPOs bajos (minutos o segundos), el backup periódico no es suficiente: se necesita replicación continua o casi continua de los datos. Las bases de datos relacionales modernas soportan replicación síncrona (cada escritura se confirma solo cuando está replicada en el destino, garantizando RPO cero) o asíncrona (la replicación sigue a la escritura con un pequeño retraso, RPO de segundos a minutos).

La replicación síncrona entre regiones no es práctica para la mayoría de los casos porque la latencia de red inter-regional es demasiado alta: cada escritura en producción esperaría la confirmación del destino de DR, degradando significativamente el rendimiento. La solución habitual es replicación síncrona dentro de la misma región (entre zonas de disponibilidad) y asíncrona entre regiones, aceptando un RPO de segundos para el failover inter-regional.

Automatización del failover: el reto del RTO bajo

Alcanzar un RTO de minutos requiere automatizar el proceso de failover. Un failover manual implica que alguien detecta el problema, escala al equipo adecuado, sigue el runbook de recuperación paso a paso y verifica el resultado. En condiciones de estrés, con personal despertado a las tres de la madrugada y sistemas parcialmente operativos, este proceso puede tardar mucho más de lo planificado.

Las soluciones como AWS Route 53 Application Recovery Controller, Azure Site Recovery o soluciones de terceros como Zerto permiten automatizar el failover: detectan automáticamente la indisponibilidad, promueven el entorno de DR y redirigen el tráfico, todo en minutos y sin intervención manual. La automatización del failover es especialmente crítica para las empresas con operación fuera del horario laboral o con presencia internacional.

1. Define RTOs y RPOs por sistema con el negocio, no de forma unilateral desde IT.
2. Clasifica los sistemas en niveles de criticidad y asigna la estrategia de DR correspondiente a cada nivel.
3. Implementa backups inmutables con retención suficiente para cubrir el período de descubrimiento de ransomware.
4. Automatiza los backups y monitoriza su ejecución y resultado: un backup que falla silenciosamente es peor que no tener backup.
5. Documenta el proceso de recuperación con un runbook detallado y actualizado.
6. Prueba el proceso de recuperación al menos una vez al año en condiciones lo más realistas posible.
7. Revisa y actualiza la estrategia después de cambios significativos en la arquitectura o en la clasificación de criticidad.

El runbook de recuperación: el documento más importante

El runbook de recuperación es el documento que guía al equipo técnico durante un incidente real. Debe ser suficientemente detallado para que alguien con conocimiento del sistema pero sin experiencia previa en la situación pueda seguirlo correctamente bajo presión. Incluye: los pasos exactos a ejecutar, las personas a contactar y su información de contacto alternativa, los accesos necesarios y dónde encontrarlos, los criterios para declarar el incidente completado y los pasos de verificación post-recuperación.

Un runbook que no se actualiza cuando cambia la arquitectura es un runbook que fallará en el peor momento. Establece un proceso para mantenerlo sincronizado con los cambios del sistema: idealmente, la actualización del runbook es parte del Definition of Done de cualquier cambio de infraestructura significativo.

Pruebas de DR: la práctica que todos posponen

El único backup que importa es el que se ha restaurado con éxito. El único plan de DR que vale es el que se ha ejecutado bajo condiciones similares a las reales. Las pruebas de DR son la práctica más pospuesta en el ciclo de vida de la seguridad porque interrumpen la operación, requieren coordinación entre equipos y consumen tiempo que siempre parece más necesario para otras tareas.

Las empresas más maduras en gestión de continuidad de negocio hacen del ejercicio de DR una práctica regular y planificada. Netflix popularizó el concepto de Chaos Engineering con su herramienta Chaos Monkey, que introduce fallos deliberados en producción para verificar la resiliencia del sistema. Para la mayoría de las organizaciones, un ejercicio anual de DR completo y pruebas trimestrales de restauración de backups es un punto de partida razonable.

• Programa pruebas de restauración de backup mensualmente para los sistemas más críticos.
• Realiza un ejercicio de DR completo al menos una vez al año, documentando el tiempo real de recuperación y comparándolo con el RTO objetivo.
• Involucra al negocio en los ejercicios de DR: deben saber qué esperar y validar que el sistema recuperado funciona correctamente.
• Documenta las lecciones aprendidas de cada ejercicio y actualiza el runbook en consecuencia.
• Considera gamegames o ejercicios de mesa (tabletop exercises) para probar la coordinación entre equipos sin necesidad de ejecutar un failover real.

Cumplimiento normativo y DR

Para muchas empresas europeas, la estrategia de DR no es solo una decisión de gestión de riesgos sino también un requisito normativo. El RGPD exige medidas técnicas y organizativas que garanticen la disponibilidad y resiliencia de los sistemas de tratamiento de datos personales, así como la capacidad de restaurar la disponibilidad de los datos en caso de incidente. La directiva NIS2, en vigor desde octubre de 2024, establece requisitos específicos de gestión de continuidad de negocio para los sectores esenciales e importantes.

En el ámbito de la Administración pública española, el Esquema Nacional de Seguridad (ENS) establece en sus controles de protección de la información requisitos específicos sobre copias de seguridad y recuperación. Documentar la estrategia de DR, los RTOs y RPOs de cada sistema, los procedimientos de recuperación y los resultados de las pruebas es fundamental tanto para el cumplimiento normativo como para las auditorías de seguridad.

Conclusión: el DR como inversión, no como gasto

La estrategia de backup y recuperación ante desastres no es un gasto de overhead de IT: es una inversión en la continuidad del negocio cuya rentabilidad se materializa en el momento del incidente. Una empresa que puede recuperar sus sistemas críticos en minutos en lugar de días tiene una ventaja competitiva real en resiliencia operativa.

El primer paso para mejorar tu postura de DR es hacer un inventario honesto: ¿qué sistemas tienes, cuáles son críticos para el negocio, qué RTOs y RPOs serían aceptables y cuál es tu situación actual? Con ese diagnóstico sobre la mesa, las prioridades de inversión se vuelven evidentes. No hace falta implementar activo-activo para todos los sistemas desde el primer día: avanza desde donde estás, con los sistemas más críticos primero, y construye la capacidad de forma incremental.