Respaldos y Disaster Recovery en Azure: qué debe considerar tu empresa

Una estrategia de recuperación en Azure debe combinar respaldos, replicación, seguridad, recuperación por región y pruebas periódicas. Azure Backup protege datos y puntos de recuperación; Azure Site Recovery mantiene cargas replicadas y orquesta failover. La arquitectura debe definirse según RTO, RPO, criticidad, cumplimiento y costo financiero de la interrupción.

Definiciones taxonómicas

1. Azure Backup. Servicio administrado de Microsoft para proteger datos y cargas de trabajo mediante políticas de respaldo, retención y recuperación. Puede proteger recursos de Azure y entornos locales, incluyendo máquinas virtuales, archivos, discos, bases de datos, blobs, AKS y determinados servidores on-premises.

2. Azure Site Recovery. Servicio de continuidad que replica cargas desde un sitio primario hacia una ubicación secundaria. Permite ejecutar failover, operar temporalmente desde el destino y realizar failback cuando el sitio original vuelve a estar disponible.

3. RTO y RPO

RTO — Recovery Time Objective: tiempo máximo que un proceso o sistema puede permanecer indisponible.
RPO — Recovery Point Objective: cantidad máxima de datos que el negocio puede aceptar perder, medida en tiempo.
Ejemplo: un RTO de dos horas exige recuperar la operación dentro de ese periodo; un RPO de 15 minutos exige que la pérdida de información no exceda aproximadamente los últimos 15 minutos.

RTO y RPO no deben definirse por preferencia técnica. Deben derivarse del impacto financiero, operativo, contractual y regulatorio.

Tabla comparativa: Backup, Disaster Recovery y alta disponibilidad

Variable	Azure Backup	Azure Site Recovery	Alta disponibilidad
Objetivo	Recuperar datos o sistemas desde puntos anteriores	Mantener una réplica y recuperar la operación en otra ubicación	Evitar o reducir interrupciones por fallas locales
Protege contra	Borrado, corrupción, ransomware, errores y pérdida de información	Caída de sitio, región, infraestructura o máquinas	Falla de instancia, host o zona, según arquitectura
Mecanismo	Copias y puntos de recuperación	Replicación, failover y failback	Redundancia activa, balanceo y distribución
RPO	Depende de la frecuencia y tecnología de respaldo	Puede ser bajo mediante replicación continua	Cercano a cero en arquitecturas adecuadas
RTO	Depende del tiempo de restauración	Diseñado para recuperación orquestada	Generalmente menor para fallas contempladas
Recuperación histórica	Sí	Limitada a puntos de replicación disponibles	No es su función principal
Retención de largo plazo	Sí	No sustituye la retención de backup	No
Pruebas	Restauración controlada	Simulacros de failover sin interrumpir la replicación	Pruebas de disponibilidad y conmutación
Caso de uso	Recuperar archivos, bases, VMs o versiones anteriores	Recuperar una aplicación o ambiente completo	Mantener un servicio operativo ante fallas
Riesgo si se usa solo	Restauración demasiado lenta para el negocio	Replica errores, corrupción o ataques si no existe backup	No protege versiones históricas ni borrado lógico

Por qué un respaldo no es un Disaster Recovery Plan

Una copia de seguridad responde a la pregunta:

¿Podemos recuperar los datos o el sistema?

Un plan de Disaster Recovery responde a preguntas adicionales:

¿En cuánto tiempo?
¿Con cuánta pérdida de datos?
¿En qué infraestructura?
¿En qué orden deben recuperarse los componentes?
¿Cómo accederán los usuarios?
¿Qué sucederá con las identidades?
¿Cómo se redirigirá el tráfico?
¿Quién autoriza el failover?
¿Cómo se validará la integridad?
¿Cómo se comunicará el incidente?
¿Cómo regresará la operación al sitio principal?

Microsoft diferencia explícitamente ambas capacidades: Azure Backup conserva datos recuperables, mientras que Azure Site Recovery replica cargas y permite conmutar hacia una ubicación secundaria durante una interrupción.

Una empresa puede tener respaldos exitosos y aun así incumplir su RTO. También puede tener una réplica disponible, pero carecer de una versión limpia anterior al ataque. Por eso, respaldo, replicación y alta disponibilidad deben operar como capas complementarias.

1. Comenzar con un Business Impact Analysis

Antes de crear vaults, políticas o réplicas, la empresa debe identificar:

Procesos críticos.
Aplicaciones que los soportan.
Usuarios afectados.
Dependencias tecnológicas.
Ingresos comprometidos.
Penalizaciones contractuales.
Obligaciones regulatorias.
Impacto reputacional.
Trabajo manual alternativo.
Tiempo máximo tolerable de interrupción.
Datos que no pueden reconstruirse.
Secuencia necesaria de recuperación.

Clasificación sugerida

Nivel 1: misión crítica

Procesamiento de pagos.
Canales de venta.
Sistemas clínicos.
Operación de planta.
Banca digital.
ERP financiero en cierres.
Identidad y autenticación.
Integraciones transaccionales.

Estos servicios suelen requerir RTO y RPO exigentes, replicación, automatización y pruebas frecuentes.

Nivel 2: crítico para operación

Herramientas de colaboración.
Aplicaciones departamentales.
Portales internos.
Repositorios operativos.
Sistemas de logística.
Plataformas de servicio.

Pueden aceptar periodos moderados de indisponibilidad, pero necesitan procedimientos documentados.

Nivel 3: recuperable

Archivos históricos.
Ambientes no productivos.
Información replicable.
Sistemas con procesos manuales temporales.
Datos de consulta no urgente.

Pueden utilizar retenciones más largas y recuperación bajo demanda.

Tratar todas las cargas como Nivel 1 aumenta innecesariamente el costo. Tratar todas como Nivel 3 expone el EBITDA.

2. Definir RTO y RPO con cifras de negocio

Para calcular el RTO

Considere:

Ingreso por hora.
Margen de contribución.
Nómina improductiva.
Penalizaciones.
Operaciones no procesadas.
Clientes afectados.
Costos de contingencia.
Requisitos regulatorios.
Daño reputacional.
Efecto acumulado sobre otros procesos.

Fórmula orientativa:

Costo por hora de interrupción × horas de recuperación

Para calcular el RPO

Determine:

Cuántas transacciones se generan por minuto.
Qué datos pueden reconstruirse.
Qué información depende de terceros.
Cuánto cuesta reconciliarla.
Qué registros tienen valor legal.
Qué pérdida generaría multas o incumplimiento.
Cuánto trabajo tendría que repetirse.

Un RPO de cero tiene implicaciones arquitectónicas y económicas muy distintas de un RPO de 24 horas. La decisión debe justificarse con impacto, no con frases como “todo es importante”.

3. Mapear las cargas de trabajo

Azure Backup puede proteger diferentes fuentes, entre ellas:

Máquinas virtuales Windows y Linux.
Azure Managed Disks.
Azure Files.
SQL Server en Azure VMs.
SAP HANA en Azure VMs.
PostgreSQL.
Azure Blobs.
Azure Kubernetes Service.
Azure Data Lake Storage.
Archivos, carpetas y servidores on-premises mediante componentes compatibles.

La empresa debe confirmar para cada carga:

Compatibilidad.
Consistencia de aplicación.
Frecuencia.
Retención.
Tamaño.
Velocidad de cambio.
Tiempo estimado de restauración.
Dependencias.
Región de origen.
Región de recuperación.
Requisitos de cifrado.
Necesidad de restauración granular.
Necesidad de recuperación completa.

4. Diseñar la arquitectura de Azure Backup

Elegir el vault adecuado

Azure utiliza vaults para almacenar:

Copias protegidas.
Puntos de recuperación.
Políticas.
Metadatos.
Historial de trabajos.
Configuración de respaldo.

Los tipos y compatibilidades varían según la fuente protegida. No todas las cargas utilizan exactamente el mismo tipo de vault.

Elegir la redundancia

Microsoft documenta tres opciones principales:

LRS — Locally Redundant Storage: mantiene varias copias dentro de la región y ofrece el menor costo relativo.
ZRS — Zone-Redundant Storage: replica los datos entre zonas de disponibilidad de una misma región.
GRS — Geo-Redundant Storage: replica los datos hacia una región secundaria.

Para cargas productivas, la guía de confiabilidad de Microsoft recomienda utilizar ZRS como nivel mínimo cuando esté disponible. Cuando se utilice GRS, debe evaluarse Cross Region Restore para restaurar en la región emparejada sin depender exclusivamente de una declaración formal de desastre.

Precaución de diseño

La redundancia del backup debe definirse antes de proteger cargas, porque determinadas configuraciones quedan bloqueadas una vez que inicia la protección. Cambiar posteriormente puede requerir un nuevo vault, reasignación y actividades adicionales.

5. Diseñar Azure Site Recovery

Azure Site Recovery puede replicar:

Máquinas virtuales entre regiones de Azure.
VMware hacia Azure.
Hyper-V hacia Azure.
Servidores físicos compatibles.
Determinadas cargas desde Azure Stack o ambientes híbridos.

Elementos que deben definirse

Región primaria.
Región secundaria.
Red virtual de recuperación.
Subredes.
Direcciones IP.
DNS.
Load balancers.
Reglas de seguridad.
Identidades.
Accesos administrativos.
Capacidad de cómputo.
Cuotas.
Almacenamiento.
Dependencias externas.
Conectividad con on-premises.
Orden de arranque.
Scripts.
Validaciones.
Procedimiento de failback.

Recovery plans

Los recovery plans permiten:

Agrupar máquinas.
Definir secuencias.
Separar capas de aplicación.
Insertar acciones manuales.
Ejecutar scripts.
Integrarse con Azure Automation.
Coordinar recuperación de aplicaciones multicapa.

Una aplicación no se recupera únicamente encendiendo máquinas. Primero pueden requerirse identidad, red, base de datos, middleware, integraciones y finalmente la capa de usuario.

Replicación y objetivos

Azure Site Recovery ofrece replicación continua para determinados escenarios. Microsoft documenta frecuencias de hasta 30 segundos para Hyper-V y la posibilidad de reducir tiempos mediante integración con servicios de administración de tráfico. Los resultados reales dependen de la carga, red, región, arquitectura y pruebas.

6. Proteger los respaldos frente a ransomware

Un respaldo conectado pero administrado con las mismas identidades comprometidas puede ser eliminado o modificado por un atacante.

La arquitectura debe incluir varias capas.

Aislamiento de datos

Azure Backup almacena los datos protegidos de forma aislada respecto del entorno productivo. Los usuarios externos o invitados no tienen acceso directo al almacenamiento administrado donde residen los respaldos.

Soft delete

Soft delete retrasa la eliminación permanente y permite recuperar información borrada accidental o maliciosamente.

Microsoft establece:

Retención predeterminada de 14 días.
Posibilidad de extenderla hasta 180 días.
Protección sobre elementos y vaults en los escenarios compatibles.

Inmutabilidad

Un vault inmutable bloquea operaciones que podrían eliminar puntos de recuperación o reducir su retención.

La configuración puede:

Habilitarse.
Bloquearse.
Convertirse en irreversible.
Utilizar almacenamiento WORM cuando está disponible.

Microsoft señala que el bloqueo irreversible debe aplicarse después de validar cuidadosamente el impacto operativo, porque impide deshabilitar posteriormente la inmutabilidad.

Para organizaciones en México, Microsoft incluye Mexico Central entre las regiones con disponibilidad general de almacenamiento WORM para Recovery Services vaults inmutables y bloqueados, sujeto a las cargas compatibles indicadas por el servicio.

Autorización multiusuario

Multi-User Authorization utiliza Resource Guard para exigir autorización adicional sobre operaciones críticas.

El diseño recomendado separa:

Administrador del vault.
Propietario de Resource Guard.
Permisos para operaciones sensibles.
Suscripción o tenant, cuando se necesita mayor aislamiento.

Resource Guard puede proteger acciones como:

Eliminar protección.
Reducir retención.
Deshabilitar soft delete.
Modificar cifrado.
Deshabilitar inmutabilidad.
Retirar la propia protección MUA.

Cifrado

Los respaldos se cifran de manera predeterminada con claves administradas por la plataforma. En escenarios que requieren control directo de claves, pueden utilizarse claves administradas por el cliente mediante Azure Key Vault, de acuerdo con la compatibilidad y configuración correspondiente.

7. Separar funciones y privilegios

Como mínimo deben diferenciarse:

Administrador de producción.
Administrador de respaldos.
Administrador de seguridad.
Responsable de Resource Guard.
Aprobador de failover.
Responsable del negocio.
Auditor.
Equipo de respuesta a incidentes.

Una sola cuenta con permisos para administrar producción, borrar respaldos, modificar retención y ejecutar failover representa una concentración de riesgo.

8. Probar la recuperación

Un backup exitoso demuestra que el trabajo terminó. No demuestra que la aplicación pueda operar.

El programa de pruebas debe incluir:

Restauración de archivos.
Recuperación de bases de datos.
Restauración de una VM.
Recuperación en red aislada.
Validación de integridad.
Pruebas de autenticación.
Conectividad con dependencias.
Pruebas de aplicación.
Simulacro de failover.
Prueba de failback.
Medición del RTO real.
Medición del RPO real.
Documentación de desviaciones.

Azure Site Recovery permite ejecutar simulacros sin afectar la replicación en curso. Esto facilita validar el plan sin detener el entorno productivo.

Frecuencia sugerida según criticidad

Misión crítica: trimestral o ante cambios relevantes.
Crítica: semestral.
Recuperable: anual.
Componentes modificados: después de cambios de arquitectura.
Controles contra ransomware: después de cambios de identidad, seguridad o retención.

La frecuencia final debe definirse conforme a regulación, contratos y nivel de riesgo.

9. Diseñar la observabilidad y las alertas

La empresa debe monitorear:

Trabajos fallidos.
Cargas sin protección.
Retrasos de replicación.
Puntos de recuperación.
Cambios de política.
Reducción de retención.
Eliminaciones.
Desactivación de controles.
Salud del vault.
Capacidad.
Estado de agentes.
Eventos de Azure Service Health.
Pruebas pendientes.
Excepciones al RTO o RPO.

Azure ofrece monitoreo centralizado, alertas e integración con Azure Monitor para ampliar reportes y seguimiento.

10. Considerar la responsabilidad compartida

Microsoft opera la infraestructura del servicio, pero la empresa sigue siendo responsable de:

Clasificar cargas.
Seleccionar redundancia.
Configurar políticas.
Definir retención.
Habilitar Cross Region Restore.
Proteger identidades.
Configurar inmutabilidad.
Establecer MUA.
Probar restauraciones.
Diseñar dependencias.
Validar los RTO y RPO.
Mantener procedimientos.
Tomar la decisión de failover.

Microsoft describe la confiabilidad en Azure como una responsabilidad compartida: la plataforma proporciona capacidades, pero el cliente debe seleccionar y configurar las necesarias para cumplir sus objetivos de negocio.

11. Construir el caso financiero

Costos tecnológicos

Instancias protegidas.
Capacidad de almacenamiento.
Retención.
Redundancia.
Región secundaria.
Cómputo durante pruebas.
Replicación.
Conectividad.
Licenciamiento complementario.
Observabilidad.
Operación administrada.

Costos de gobierno

Pruebas.
Documentación.
Auditoría.
Gestión de cambios.
Capacitación.
Simulacros.
Actualización del plan.
Respuesta a incidentes.

Beneficios financieros

Horas de indisponibilidad evitadas.
Transacciones preservadas.
Penalizaciones evitadas.
Reducción del esfuerzo de recuperación.
Menor dependencia de procesos manuales.
Protección del ingreso.
Continuidad de producción.
Menor impacto reputacional.
Evidencia de cumplimiento.

Evidencia de impacto

En un caso documentado por Scanda, la implementación de un plan de recuperación con dos hyperscalers redujo de 48 a 12 horas el tiempo requerido para restaurar servicios críticos después de un desastre mayor. Esto equivale a 36 horas menos de interrupción y una reducción de 75% sobre el tiempo previo de recuperación.

El valor financiero de esas 36 horas debe calcularse con base en:

Ingreso por hora.
Margen.
Usuarios afectados.
Producción detenida.
Penalizaciones.
Operaciones no procesadas.
Costo de recuperación.
Daño contractual y reputacional.

El dato importante no es únicamente “recuperar en 12 horas”. Es demostrar qué procesos pueden volver a operar, con qué integridad, qué pérdida de información y qué impacto económico residual.

Errores que debe evitar la empresa

Confundir replicación con respaldo. La replicación puede copiar corrupción, cifrado malicioso o eliminaciones. Se requieren puntos históricos protegidos.
Mantener todo en una sola región. Una arquitectura regional sin estrategia secundaria puede ser insuficiente para el RTO acordado.
No proteger el plano de administración. Si el atacante compromete las identidades administrativas, puede intentar deshabilitar controles o eliminar puntos de recuperación.
Definir RTO y RPO sin el negocio. TI puede estimar tiempos técnicos, pero Finanzas, Operaciones, Riesgos y Cumplimiento deben determinar la tolerancia real.
No incluir dependencias. Una VM recuperada no sirve si carece de DNS, identidad, base de datos, integración o conectividad.
No probar failback. Recuperar en la región secundaria es solo la mitad del proceso. La organización debe saber cómo volver a la operación normal.

Medir únicamente backups exitosos

Los indicadores relevantes son:

Capacidad real de recuperación.
Tiempo real de restauración.
Pérdida real de datos.
Cumplimiento del RTO.
Cumplimiento del RPO.
Integridad de la aplicación.
Evidencia del simulacro.

El papel de Scanda

Scanda ayuda a construir una capacidad de resiliencia, no únicamente una configuración de backup.

El servicio puede incluir:

Business Impact Analysis.
Clasificación de aplicaciones.
Definición de RTO y RPO.
Assessment de Azure.
Arquitectura de respaldos.
Diseño de Site Recovery.
Configuración de redundancia.
Cross Region Restore.
Inmutabilidad.
Resource Guard.
Controles de identidad.
Recovery plans.
Automatización.
Simulacros.
Tableros ejecutivos.
Documentación.
Gobierno continuo.
Optimización de costos.
Acompañamiento de un Outcome Owner.

Scanda posiciona la continuidad como un resultado de negocio medible: disponibilidad, tiempo de recuperación, riesgo residual, costo de interrupción y evidencia para dirección o auditoría.

Conclusión predictiva

El respaldo aislado dejará de ser suficiente para organizaciones sujetas a ransomware, operaciones distribuidas y dependencias digitales crecientes. Las arquitecturas maduras combinarán recuperación histórica, replicación, inmutabilidad, autorización multiusuario, segregación de funciones y simulacros con evidencia.

La ventaja no será “tener Azure”, sino demostrar que la empresa puede recuperar procesos críticos dentro de límites financieros aprobados. Las organizaciones que no midan su RTO y RPO reales descubrirán la brecha durante el incidente, cuando cada hora sea más costosa y haya menos margen para corregirla.

FAQ

1. ¿Azure Backup y Azure Site Recovery son lo mismo? No. Azure Backup conserva copias y puntos históricos para restaurar datos o sistemas. Azure Site Recovery replica cargas y orquesta failover hacia otra ubicación. Una estrategia completa puede necesitar ambos servicios.

2. ¿Cómo debe definir una empresa su RTO y RPO? Debe partir del Business Impact Analysis. El RTO se define según cuánto tiempo puede permanecer detenido el proceso. El RPO se define según cuántos datos puede perder la empresa sin causar un impacto inaceptable.

3. ¿Azure garantiza por sí solo que la empresa pueda recuperarse? No. Azure proporciona capacidades de backup, replicación, redundancia y seguridad, pero la empresa debe configurarlas, protegerlas, integrarlas con sus aplicaciones y probarlas periódicamente.

¿Su empresa tiene respaldos o puede demostrar que realmente se recuperará?

Scanda puede evaluar:

Qué procesos requieren Disaster Recovery.
Qué cargas están desprotegidas.
Si el RTO y RPO son financieramente correctos.
Cuánto tardaría una restauración real.
Si los respaldos resisten un ataque.
Qué dependencias no están incluidas.
Qué región, redundancia y retención necesita.
Cuánto cuesta mantener la arquitectura.
Qué controles deben probarse.

Agende una sesión ejecutiva con Scanda para convertir sus respaldos y servicios de Azure en una capacidad comprobable de continuidad, seguridad y resiliencia empresarial.