Disaster Recovery en nube híbrida: cómo recuperar cuando tus datos viven en dos entornos

Un Disaster Recovery en nube híbrida debe recuperar servicios de negocio completos aunque sus datos, aplicaciones, identidades y dependencias estén distribuidos entre infraestructura local y cloud. El diseño parte del BIA, asigna RTO y RPO por criticidad, mapea dependencias entre entornos y define replicación, failover, operación degradada, failback y pruebas periódicas.

Disaster Recovery Plan (DRP). Conjunto documentado y probado de procedimientos, arquitectura, responsables y tecnologías para restaurar sistemas y datos después de una interrupción. En Pulse lo vinculamos con BIA, BCP, RTO, RPO, funciones mínimas, estrategias de recuperación, crisis, pruebas y simulaciones; la recuperación debe partir de los procesos críticos y no únicamente de la tecnología.
Nube híbrida. Arquitectura en la que aplicaciones, datos y servicios operan mediante una combinación de infraestructura privada/on-premise y servicios de nube pública. El reto de continuidad no es simplemente proteger ambos ambientes, sino preservar las dependencias que permiten que una función de negocio opere de extremo a extremo.
RTO y RPO. El Recovery Time Objective (RTO) define el máximo tiempo de indisponibilidad aceptable; el Recovery Point Objective (RPO) determina la pérdida máxima de datos aceptable expresada en tiempo. Microsoft señala que cada componente o flujo de una carga puede necesitar valores distintos de RTO y RPO según su impacto de negocio.

¿Qué cambia en un DRP cuando la operación está distribuida?

Variable	DR tradicional / entorno único	DR en nube híbrida	Riesgo si no se controla
Datos	Un repositorio o infraestructura principal	Datos distribuidos entre on-premise y cloud	Recuperar versiones inconsistentes
Aplicaciones	Dependencias relativamente concentradas	Servicios locales, cloud, SaaS, APIs y microservicios	Recuperar una aplicación que sigue inutilizable
Identidad	Directorio central	AD, Entra ID, federación, MFA, roles y cuentas privilegiadas	Infraestructura disponible sin usuarios capaces de acceder
Conectividad	Red corporativa	WAN, VPN, DNS, enlaces privados, Internet y cloud networking	Recursos recuperados pero aislados
RPO	Puede depender de un esquema único de respaldo	Debe definirse por workload y flujo de datos	Pérdida de transacciones
RTO	Recuperación de infraestructura	Recuperación del servicio de negocio end-to-end	Cumplir el RTO técnico pero no el operativo
Failover	Generalmente dentro de la misma arquitectura	Puede cruzar datacenter, región o proveedor	Procedimientos manuales lentos
Failback	Regreso al sitio primario	Reconciliación entre múltiples fuentes y ambientes	Pérdida o duplicidad de información
Pruebas	Restauración de backup	Recuperación integral de dependencias	Falsa sensación de continuidad
Costo	Capacidad secundaria dedicada	Puede combinar backup, pilot light, warm standby y active-active	Sobreinvertir en sistemas no críticos

La distinción económica es importante. AWS clasifica las estrategias de DR desde backup and restore, con menor costo y recuperación medida normalmente en horas, hasta multi-site active/active, con mayor costo y complejidad pero RTO/RPO cercanos a cero. Entre ambos se encuentran pilot light y warm standby.

1. Empieza por el negocio, no por Azure, AWS ni el datacenter

El primer error de un DRP híbrido es dibujar la arquitectura de recuperación antes de responder una pregunta mucho más incómoda:

¿Qué funciones del negocio tienen que seguir operando cuando una parte de la infraestructura deja de existir?

En Pulse trabajamos la continuidad desde esa pregunta. Nuestro modelo comienza identificando las funciones críticas, después incorpora contexto regulatorio y contractual y posteriormente mapea sistemas, datos, identidades, proveedores y personas de las que depende cada función. Por ejemplo, una empresa podría tener:

ERP en infraestructura privada.
Base de datos secundaria en Azure.
Portal de clientes en AWS.
Identidades sincronizadas con Microsoft Entra ID.
Respaldos en almacenamiento cloud.
APIs conectadas con proveedores externos.
DNS administrado por un tercero.
Procesos operativos que todavía dependen de personas y procedimientos manuales.

Tener respaldo del ERP no significa poder recuperar esa operación. El DRP debe proteger la cadena completa que produce el servicio. El BIA determina qué merece recuperarse primero. El Business Impact Analysis debe cuantificar, por función:

impacto financiero por hora de indisponibilidad;
ingresos o transacciones comprometidas;
obligaciones regulatorias;
penalizaciones contractuales;
impacto operacional;
dependencias tecnológicas;
dependencia de terceros;
pérdida máxima tolerable de datos;
tiempo máximo tolerable de interrupción.

Ese análisis permite evitar uno de los errores más costosos de continuidad: asignar el mismo nivel de protección a todo. Un servidor que soporta facturación crítica y un repositorio histórico no deberían recibir automáticamente la misma arquitectura de DRP.

2. Asigna RTO y RPO por servicio, no por infraestructura completa

Microsoft recomienda definir RPO y RTO considerando cada flujo o componente de la carga y las consecuencias particulares de pérdida de información e indisponibilidad.

Eso cambia una conversación típica: “Necesitamos recuperar todo en dos horas.” Por una mucho más útil: “¿Qué debe estar funcionando a las dos horas, qué puede esperar ocho y qué puede recuperarse al día siguiente?” Una clasificación práctica podría verse así:

Criticidad	Ejemplo	RTO objetivo	RPO objetivo	Estrategia probable
Crítica	Transacciones, pagos, producción	Minutos	Segundos/minutos	Warm/hot standby o active-active
Alta	ERP, logística, operación	1–4 horas	Minutos/horas	Replicación + warm standby
Media	Aplicaciones administrativas	4–12 horas	Horas	Pilot light
Baja	Archivo o históricos	12–24+ horas	Horas/día	Backup & restore

Los tiempos son ilustrativos, no SLA universales. Los valores reales deben surgir del BIA y del costo de indisponibilidad. AWS documenta precisamente este intercambio entre costo y recuperación: backup and restore puede trabajar con RTO de horas; pilot light puede reducirlo a decenas de minutos; warm standby puede llevarlo a minutos; y active-active puede aproximarlo a cero, a cambio de mayor costo y complejidad.

La pregunta financiera, por tanto, no es “¿cuánto cuesta el DR?”, sino: ¿Cuánto cuesta reducir una hora adicional de recuperación y cuánto dinero protege esa hora?

Ahí empieza un business case defendible ante el CFO.

3. Construye el mapa de dependencias entre los dos entornos

Éste es el corazón del Disaster Recovery híbrido. Una aplicación rara vez depende únicamente de su servidor. Puede requerir:

Aplicación → Base de datos → Identidad → DNS → Red → API → Certificado → Tercero → Usuario

Si cualquiera de esas piezas permanece caída, el servicio no está recuperado. Por eso, en Pulse consideramos que una métrica crítica es el porcentaje de funciones críticas con dependencias mapeadas. Otra es el porcentaje de recuperaciones realmente probadas y el cumplimiento efectivo de RTO/RPO. Tener esos valores únicamente escritos en un documento no demuestra resiliencia. El mapa mínimo debe incluir:

aplicaciones;
bases de datos;
almacenamiento;
identidades y privilegios;
DNS;
certificados;
redes y conectividad;
APIs;
integraciones;
SaaS;
proveedores externos;
jobs y automatizaciones;
herramientas de seguridad;
monitoreo;
respaldos;
dependencias humanas.

Después hay que identificar puntos únicos de falla. Un DRP puede tener infraestructura redundante y seguir dependiendo de un único DNS, un único enlace o una sola persona que conoce la secuencia de recuperación.

4. Decide qué se replica, qué se reconstruye y qué se restaura

No todo necesita replicación continua. Una arquitectura económicamente sostenible combina mecanismos según criticidad.

Backup & Restore: Adecuado cuando el negocio tolera tiempos mayores de recuperación.Se conservan respaldos y, durante la contingencia, se reconstruye la infraestructura y se restauran datos.AWS lo coloca como la estrategia de menor costo relativo, pero también con mayores RTO/RPO frente a esquemas de standby.
Pilot Light: Los componentes esenciales permanecen disponibles y los demás se aprovisionan durante la recuperación.AWS sitúa este patrón típicamente en RPO de minutos y RTO de decenas de minutos, aunque el resultado real depende de la arquitectura y automatización.
Warm Standby: Existe una versión funcional pero reducida del ambiente secundario. Durante el desastre se escala para absorber la carga productiva.AWS describe este esquema con RPO que puede medirse en segundos y RTO en minutos para arquitecturas adecuadamente diseñadas.
Active-Active: Dos ambientes atienden tráfico simultáneamente.Puede acercarse a RTO/RPO cero, pero aumenta significativamente el costo y la complejidad operativa. Además, replicación no equivale a backup: una corrupción de datos también puede replicarse al ambiente secundario, por lo que siguen siendo necesarios mecanismos de recuperación point-in-time.

Ese último punto suele olvidarse: más replicación no siempre significa más capacidad de recuperación.

5. Diseña la recuperación del dato, pero también su consistencia

Supongamos que una transacción genera simultáneamente:

un pedido en una aplicación cloud;
un registro en el ERP on-premise;
una actualización de inventario;
un movimiento financiero;
un evento enviado a otra plataforma.

Recuperar cada base de datos de manera independiente puede generar cuatro sistemas técnicamente disponibles pero con estados temporales distintos. Por eso el RPO debe analizarse también entre dependencias. Hay que responder previamente

¿Cuál sistema es la fuente autoritativa?
¿Qué información se replica de forma síncrona?
¿Qué información se replica de forma asíncrona?
¿Cómo se detectan transacciones incompletas?
¿Qué sistema puede operar temporalmente sin el otro?
¿Cómo se reconciliarán los datos después del failover?
¿Qué ocurre si el origen vuelve a estar disponible con información diferente?

Sin esas respuestas, el problema posterior al desastre deja de ser disponibilidad y se convierte en integridad del dato.

6. No olvides identidad, DNS y conectividad

Uno de los peores resultados de una prueba de DR es éste: Los servidores arrancaron. Nadie puede entrar. En un entorno híbrido, recuperar compute y almacenamiento no garantiza acceso. Hay que probar también:

autenticación;
cuentas privilegiadas;
MFA;
directorios;
sincronización de identidades;
DNS;
certificados;
VPN;
rutas;
firewalls;
políticas de acceso;
secretos y llaves;
resolución de nombres.

La arquitectura de continuidad debe asumir que alguno de estos servicios también puede ser parte del incidente. El objetivo es evitar que el ambiente secundario dependa precisamente del componente que acaba de fallar.

7. Automatiza la recuperación donde el RTO lo justifique

Un runbook de 47 pasos ejecutado manualmente a las tres de la mañana no es precisamente el mejor aliado de un RTO agresivo. AWS recomienda automatizar componentes del DR como redespliegue de infraestructura, configuración y código para reducir carga manual y margen de error. En nube híbrida conviene automatizar, cuando sea viable:

aprovisionamiento mediante Infrastructure as Code;
activación de workloads;
configuración de networking;
cambio de DNS;
escalamiento de capacidad;
validaciones de salud;
secuencia de arranque;
verificación de dependencias;
generación de evidencia.

Pero automatizar no significa eliminar controles. Una automatización incorrecta sólo permite equivocarse mucho más rápido.

8. Diseña la operación degradada antes del desastre

Un DRP maduro no presupone que todo debe volver simultáneamente. Puede definir una Minimum Business Continuity Objective o conjunto equivalente de funciones mínimas:

qué procesos siguen operando;
qué funcionalidades se suspenden;
qué usuarios conservan acceso;
qué transacciones se priorizan;
qué procedimientos manuales entran en vigor;
qué capacidad mínima debe soportar el entorno secundario.

En Pulse consideramos especialmente relevante medir la capacidad de mantener funciones mínimas durante una contingencia. Una organización que sólo contempla restauración total carece de una opción intermedia cuando el RTO empieza a agotarse.

Eso también reduce inversión: no toda la producción necesita necesariamente un clon 1:1 esperando una contingencia.

9. Define el failback antes de ejecutar el failover

Pasar al ambiente secundario es sólo la mitad del problema. Cuando el primario vuelva, aparecerá una pregunta delicada: ¿Cuál de los dos ambientes tiene ahora la verdad?

El DRP debe establecer:

criterios para declarar recuperado el sitio primario;
sincronización inversa;
reconciliación de datos;
tratamiento de transacciones generadas durante la contingencia;
ventana de retorno;
responsables de autorización;
pruebas de integridad;
secuencia de failback;
criterios para cerrar formalmente el incidente.

Un failover improvisado puede recuperar la operación. Un failback improvisado puede volver a romperla.

10. Prueba el servicio de extremo a extremo

AWS considera la prueba de DR una práctica explícita de resiliencia y advierte que, sin una estrategia planeada, implementada y probada, es improbable cumplir los objetivos de recuperación durante un desastre real. En Pulse hacemos una distinción importante: backup ejecutado ≠ recuperación probada.

Nuestro propio marco de resiliencia identifica como señal de riesgo que una organización reporte respaldos ejecutados pero no el porcentaje de recuperaciones verificadas; también cuestionamos RTO/RPO que existen en documentos pero nunca se han contrastado contra una prueba real. Una prueba madura debe medir, como mínimo:

tiempo de detección;
tiempo de declaración del desastre;
inicio del failover;
recuperación de datos;
recuperación de aplicaciones;
autenticación;
conectividad;
recuperación de integraciones;
validación funcional del negocio;
RPO real alcanzado;
RTO real alcanzado;
errores manuales;
desviaciones del runbook;
tiempo y resultado del failback.

La métrica final no debería ser “la VM encendió”. Debería ser: “La función crítica volvió a operar dentro del RTO, con pérdida de datos dentro del RPO y con integridad validada.”

11. Traduce el DRP a riesgo financiero

Un DRP híbrido no debería justificarse sólo mediante disponibilidad técnica. El modelo económico básico es: Impacto esperado de indisponibilidad = costo por hora × horas probables de interrupción + pérdidas adicionales. El análisis puede incorporar:

ventas no realizadas;
producción detenida;
horas improductivas;
penalizaciones contractuales;
recuperación técnica;
respuesta a incidentes;
compensaciones a clientes;
impacto regulatorio;
costos extraordinarios de operación.

Después se compara contra el costo incremental de reducir RTO/RPO. Por ejemplo, si una función genera un impacto de $500,000 MXN por hora y una arquitectura reduce el tiempo probado de recuperación de ocho a dos horas, la exposición evitada en ese escenario sería: 6 horas × $500,000 = $3 millones MXN

No significa automáticamente que la inversión produzca $3 millones de ROI; significa que existe una exposición económica potencial de $3 millones por evento que puede utilizarse para evaluar el costo de mitigación. Ésa es una diferencia importante cuando el business case llega al CFO.

Grupo Scanda refuerza precisamente esta lógica: el costo por hora de indisponibilidad es la métrica que permite determinar si el argumento de continuidad tiene sustento económico.

12. El modelo de Pulse para recuperación híbrida

En Pulse by Scanda no tratamos el Disaster Recovery como un proyecto aislado de infraestructura. Nuestro enfoque de continuidad integra:

BIA;
BCP;
DRP;
RTO y RPO;
funciones mínimas de negocio;
estrategias de recuperación;
planes de crisis;
pruebas;
simulaciones;
procedimientos alternos;
gobierno de continuidad.

Además, conectamos la continuidad con seguridad y resiliencia cloud. Diseñamos y operamos entornos considerando seguridad, disponibilidad, recuperación, gobernabilidad, costos, observabilidad, automatización y arquitectura resiliente; las plataformas tecnológicas son habilitadores y la decisión depende de la criticidad y realidad de cada organización.

Nuestro marco lo resume en cuatro movimientos: anticipar, resistir, responder y recuperar, y adaptar. Durante la recuperación, el tiempo se convierte en la variable crítica: se restaura primero aquello que permite mantener el negocio, no necesariamente toda la infraestructura al mismo tiempo.

El material interno de Pulse documenta además un testimonio de DRP multi-nube como evidencia de la capacidad de Continuidad y Recuperación, aunque el cliente no está autorizado para publicación; por ello no atribuimos públicamente el resultado a una organización específica.

Ese matiz importa: en continuidad, una cifra sin contexto o sin autorización genera más ruido que autoridad.

Conclusión predictiva

La complejidad del Disaster Recovery crecerá menos por el volumen de infraestructura que por el número de dependencias entre entornos. A medida que una organización combine datacenter, nube pública, SaaS, identidades federadas, APIs y servicios administrados, será cada vez menos útil preguntar “¿tenemos backup?” y más importante preguntar “¿podemos reconstruir la función de negocio completa dentro del RTO?”

La tendencia técnica también apunta hacia una recuperación más automatizada y continuamente validada. AWS ya recomienda combinar objetivos explícitos de recuperación, automatización, control de configuración y pruebas recurrentes como componentes de una estrategia de DR.

En Pulse by Scanda consideramos que el siguiente nivel de madurez no será tener un DRP documentado, sino poder demostrar tres cosas con evidencia: qué se recupera primero, cuánto tarda realmente y cuánto negocio puede continuar mientras ocurre. La resiliencia deja entonces de ser una promesa de infraestructura y se convierte en una capacidad medible del negocio.

¿Tu DRP recupera servidores o recupera el negocio?

En Pulse by Scanda evaluamos qué funciones deben seguir operando, de qué sistemas, datos, identidades y terceros dependen, y si tus RTO y RPO pueden sostenerse en una recuperación real. Podemos partir de tu arquitectura actual —on-premise, Azure, AWS, híbrida o multi-cloud— para identificar dependencias, puntos únicos de falla, prioridades de recuperación y brechas entre el DRP documentado y la capacidad real de recuperación.

Agenda un assessment de continuidad y resiliencia con Pulse by Scanda y convierte tu DRP en una capacidad comprobable, medible y defendible ante TI, dirección y auditoría.

FAQ

¿Un backup en la nube es suficiente para tener Disaster Recovery? No. El backup protege información, pero un DRP debe recuperar también infraestructura, aplicaciones, identidades, conectividad, configuraciones, integraciones y procedimientos. AWS diferencia explícitamente backup & restore de pilot light, warm standby y active-active porque cada estrategia ofrece distintos niveles de RTO, RPO, costo y complejidad.
¿Conviene tener el DRP en otro proveedor de nube? Depende del escenario de riesgo, regulación, RTO/RPO, capacidades internas y costo. Un segundo proveedor puede reducir ciertas dependencias, pero también introduce complejidad en identidades, networking, seguridad, observabilidad, skills y operación. Multi-cloud no equivale automáticamente a mayor resiliencia: debe demostrar que reduce un riesgo concreto y que la recuperación puede probarse.
¿Cómo sabe un CIO o CFO si está pagando demasiado por Disaster Recovery? Debe comparar el costo de la arquitectura contra el impacto financiero de la indisponibilidad y la pérdida de datos. Los workloads críticos pueden justificar warm standby o active-active; cargas menos críticas pueden utilizar pilot light o backup & restore. AWS documenta precisamente que las estrategias con menores RTO/RPO aumentan en costo y complejidad.