Azure Backup: más allá de lo nativo, hacia una cobertura total

El problema con Entra ID que nadie prevé

El año pasado, un cliente me llamó para comentarme un problema que no se había visto venir. Un miembro de su equipo eliminó un registro de aplicación de Entra ID del que dependían 40 servicios internos. Los servicios comenzaron a fallar en cuestión de minutos. Intentaron restaurar el registro de la aplicación a partir de la copia de seguridad de Azure. 

La copia de seguridad de Azure no cubre Entra ID. Microsoft lo ha dejado claro en su documentación desde hace años. El cliente no lo había leído. La mayoría de los equipos tampoco. Para cuando comprendieron lo que habían perdido, ya habían dedicado dos días a reconstruir manualmente el registro de la aplicación a partir de archivos de configuración dispersos entre diferentes equipos. 

Esa llamada marcó mi forma de ver la protección en Azure. Los servicios nativos que ofrece Microsoft son elementos básicos útiles. No constituyen una protección completa, y las lagunas se encuentran precisamente en aquellos aspectos que la mayoría de los equipos dan por cubiertos de forma predeterminada. 

Donde los servicios nativos de Azure no llegan

Microsoft ofrece varios servicios de protección nativos y funcionan bien. Azure Backup se encarga de las instantáneas a nivel de máquina virtual y de la recuperación a nivel de archivo. Azure Site Recovery se encarga de la coordinación de la conmutación por error. Azure SQL cuenta con copias de seguridad automatizadas con recuperación a un momento determinado. Azure Blob Storage cuenta con opciones de control de versiones e inmutabilidad. Para muchas cargas de trabajo, estos son el punto de partida adecuado.

Las lagunas se manifiestan en cinco aspectos concretos que cobran mayor importancia cuando realmente se necesita la recuperación.

Consistencia de las aplicaciones en cargas de trabajo complejas. Las instantáneas nativas de máquinas virtuales suelen ser consistentes ante fallos. Para realizar copias de seguridad adaptadas a la aplicación de cargas de trabajo de varios niveles, SAP HANA o aplicaciones con requisitos de inactivación personalizados, se necesita un marco previo y posterior a la aplicación que garantice que los sistemas de archivos y las aplicaciones se pongan correctamente en estado de inactividad. No basta con realizar una instantánea en el estado en el que se encuentre el núcleo en ese momento.

Cobertura de SaaS. La copia de seguridad nativa de Azure no cubre Microsoft 365 ni Entra ID. La propia Microsoft afirma explícitamente que la retención y la recuperación de estos objetos a nivel de inquilino son responsabilidad del cliente. Si se pierde el registro de una aplicación de Entra ID o se elimina un sitio de SharePoint, Microsoft aplicará la acción sin que exista una vía de recuperación por parte de la propia Microsoft. 

Recuperación entre inquilinos y entre suscripciones. Los servicios nativos funcionan dentro de una única suscripción de Azure. La recuperación en una suscripción o un inquilino diferentes, o de vuelta al entorno local, resulta operativamente más compleja de lo que debería, especialmente durante un incidente en el que no se puede confiar en el entorno de origen. 

Gestión de políticas a gran escala. Cuando cientos de máquinas virtuales se distribuyen entre múltiples grupos de recursos y suscripciones, la asignación manual de políticas de copia de seguridad acaba generando lagunas de cobertura por desgaste. Las cargas de trabajo que quedan fuera son precisamente las que un atacante o un administrador descuidado acabará destruyendo.

Previsibilidad de costes fuera de los escenarios previstos. Los cargos por salida de datos, las transiciones entre niveles de retención y los costes ocultos de ejecutar servicios nativos en distintas regiones pueden sorprenderle en el mes menos oportuno, precisamente aquel en el que realmente necesite recuperar algo importante.

Ir más allá de lo nativo no significa abandonar lo nativo. Significa tratar los elementos nativos como base y añadir cobertura, coherencia y escala operativa sobre ellos. 

Lo que debe abarcar una protección completa de Azure

Qué significa realmente «diseñado específicamente para Azure»

A los proveedores les encanta esa expresión. Cuatro pruebas concretas distinguen el marketing de la arquitectura.

Instantáneas nativas a nivel de máquina virtual de Azure. El servicio de copia de seguridad debe utilizar el mecanismo de instantáneas nativo de Azure, no instantáneas del propio proveedor superpuestas, de modo que el impacto en la producción sea prácticamente nulo.

Autenticación mediante Microsoft Entra ID. La autenticación se realiza a través de Entra ID y hereda el modelo RBAC existente. Una base de datos de usuarios independiente implica una infraestructura paralela que hay que mantener sincronizada.

Distribución a través de Azure Marketplace y facturación de Azure. La suscripción se gestiona a través de Marketplace y se factura en función de los compromisos existentes con Azure. No se trata de una relación independiente de adquisición y facturación.

Reconocimiento de los grupos de recursos para la multitenencia. Los distintos equipos y unidades de negocio residen en diferentes grupos de recursos. El servicio debe detectar y respetar esa estructura automáticamente, proporcionando a cada equipo visibilidad únicamente de sus propios recursos. 

Lo que distingue una copia de seguridad básica de una de nivel operativo

Implementar la copia de seguridad es la parte fácil. Las características que determinan si la protección sigue funcionando al cabo de dos años, tras docenas de nuevas máquinas virtuales y al menos una reestructuración organizativa, son de carácter operativo más que funcional. Hay cuatro capacidades específicas que son fundamentales.

Un marco de consistencia de aplicaciones personalizado. Las instantáneas estándar de máquinas virtuales de Azure gestionan las aplicaciones comunes. Para SAP HANA, aplicaciones personalizadas o cargas de trabajo de varios niveles, un marco previo y posterior a la aplicación le permite definir cómo debe prepararse el sistema de archivos o la aplicación para la copia de seguridad. Sin él, las copias de seguridad existen, pero la recuperación resulta frágil.

Asignación automática de políticas basada en etiquetas. Defina las políticas una sola vez, alineadas con los SLA, y luego aplíquelas automáticamente en función de las etiquetas asignadas durante el aprovisionamiento. Una carga de trabajo etiquetada como «producción-nivel-1» recibe la política de nivel 1. Una carga de trabajo etiquetada como «desarrollo» recibe la política de desarrollo. Las cargas de trabajo sin etiquetar se rigen por la política predeterminada de red de seguridad. Máxima cobertura, mínima carga administrativa.

Recuperación granular. La recuperación debe permitirle elegir qué restaurar a nivel de archivo, carpeta, máquina virtual, disco virtual o aplicación completa, y dónde restaurarlo: ubicación original, máquina virtual alternativa, grupo de recursos diferente, suscripción diferente o región diferente. La granularidad cobra mayor importancia en situaciones de compromiso en las que no se puede confiar en el entorno original.

Notificaciones basadas en webhooks integradas en su pila de operaciones existente. Los eventos críticos de copia de seguridad llegan a las herramientas que su equipo ya utiliza: Slack, Microsoft Teams, ServiceNow. No a una consola independiente que nadie supervisa. Las alertas en tiempo real sobre fallos de protección marcan la diferencia entre detectar un problema a tiempo y descubrirlo durante la restauración.

Azure Government y cargas de trabajo reguladas

Las agencias federales, los contratistas de defensa y los sectores regulados tienen requisitos que van más allá de la copia de seguridad estándar de Azure. Hay tres capacidades que son fundamentales.

Compatibilidad con Azure Government Cloud. La protección debe funcionar dentro de Azure Government, no solo en Azure comercial. Para los clientes federales de EE. UU., esto incluye la copia de seguridad de datos locales en Azure Government Blob Storage como copia de seguridad de archivo o primaria, desde centros de datos centralizados, sitios periféricos, ubicaciones remotas e infraestructura móvil. 

Protección contra el ransomware basada en WORM con deduplicación eficiente en la nube. El almacenamiento WORM impide que el ransomware cifre las copias de seguridad. El reto en cuanto a costes radica en que los dispositivos de deduplicación tradicionales requieren una cantidad significativa de recursos de computación y memoria, lo cual resulta costoso en la nube. Solo almacenamos bloques únicos en la nube, lo que ahorra recursos de red, almacenamiento y computación. Dado que la recuperación no requiere rehidratación, el rendimiento de la restauración solo está limitado por el ancho de banda de la red.

Certificación FIPS 140 y soberanía de los datos controlada por el cliente. HYCU obtuvo la certificación FIPS 140-3 en 2025, cumpliendo así con los estándares federales para módulos criptográficos. Esto, junto con el compromiso arquitectónico de que los datos de los clientes nunca escapan a su control, resulta fundamental para cualquier organización sujeta a FedRAMP, ITAR, CMMC o marcos normativos similares. 

Preguntas frecuentes sobre las copias de seguridad en Azure

¿Incluye Azure ya la función de copia de seguridad o necesito una solución independiente?

Azure incluye servicios de protección nativos que gestionan instantáneas de máquinas virtuales, la recuperación de archivos y la coordinación de la recuperación ante desastres (DR) para numerosos escenarios. Sin embargo, no cubren Microsoft 365, Entra ID ni muchos de los requisitos de consistencia de las aplicaciones empresariales, y presentan limitaciones en cuanto a la recuperación entre inquilinos y la gestión de políticas a gran escala. La mayoría de los entornos empresariales necesitan un enfoque por capas: primitivas nativas más una plataforma de terceros para lograr una cobertura completa. 

¿Cómo gestiona la copia de seguridad de Azure Microsoft 365 y Entra ID?

No lo hace. El modelo de responsabilidad compartida de Microsoft atribuye al cliente la retención y la recuperación de los datos de Microsoft 365 y de los objetos de Entra ID. La recuperación granular de buzones de Exchange, sitios de SharePoint, contenido de OneDrive, datos de Teams y registros de aplicaciones o usuarios de Entra ID requiere una plataforma de terceros diseñada específicamente para esas cargas de trabajo.

¿Puedo utilizar Azure como destino de recuperación ante desastres sin tener que pagar por una infraestructura siempre activa?

Sí. Con el servicio BaaS nativo de la nube, las copias de seguridad se almacenan de forma continua en Azure Blob Storage a bajo coste. La capacidad de computación y el almacenamiento de alto rendimiento solo se consumen cuando se declara un escenario de recuperación ante desastres. La mayor parte del año se paga por el almacenamiento. En los contados casos en que se produce un desastre, se paga por la capacidad de computación. Una fracción del coste de un sistema en espera totalmente aprovisionado.

¿Cuál es la diferencia entre Azure Backup y una plataforma BaaS dedicada?

Azure Backup es el servicio nativo de Microsoft para proteger máquinas virtuales de Azure, Azure Files y cargas de trabajo de SQL dentro de Azure. Una plataforma BaaS dedicada se superpone a esta para añadir copias de seguridad coherentes con las aplicaciones en todas las aplicaciones empresariales, cobertura de SaaS (Microsoft 365, Entra ID), gestión centralizada de políticas entre suscripciones y inquilinos, integración de webhooks y recuperación ante desastres entre nubes. Ambas soluciones son complementarias. 

Si solo va a hacer una cosa

Audite hoy mismo su cobertura de Microsoft 365 y Entra ID. Haga un listado de lo que se copia, con qué herramienta y qué se necesitaría para recuperar un registro de aplicación, un sitio de SharePoint o un usuario crítico eliminados accidentalmente. Si la respuesta a cualquiera de estas preguntas es «lo reconstruiríamos desde cero», tiene una laguna que conviene subsanar antes de que alguien cometa el mismo error que el cliente del ejemplo inicial.