Microsoft AZ-801: Recuperación ante desastres y continuidad del negocio — Guía de estudio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Forma parte de la Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

El diseño de la recuperación ante desastres (DR) y la continuidad del negocio (BC) comienza cuantificando dos métricas: el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). El RTO representa la rapidez con la que se debe restaurar el servicio; el RPO define cuánta pérdida de datos (en tiempo) es aceptable. Estos valores determinan las elecciones de tecnología, la topología y el costo. Un RTO bajo favorece la orquestación y la automatización (planes de recuperación de Azure Site Recovery, runbooks y recursos de destino creados previamente). Un RPO bajo favorece la replicación continua (ASR) o la confirmación síncrona (SQL Always On), mientras que un RPO más alto puede depender de copias de seguridad periódicas (Azure Backup, Windows Server Backup). Los grupos de coherencia de múltiples VM y las instantáneas coherentes con la aplicación preservan la integridad transaccional entre VM cuando se requiere un RPO estricto. La elección del almacén (Recovery Services vault frente a Backup vault), el diseño de la directiva de replicación y la programación de copias de seguridad se seleccionan para cumplir estos objetivos sin exceder el presupuesto.

Azure Site Recovery: Hyper-V, VMware, orquestación y coherencia

Azure Site Recovery (ASR) proporciona replicación continua y conmutación por error/conmutación por recuperación orquestadas para máquinas virtuales de VMware, Hyper-V locales y de Azure IaaS.

Protección de Hyper-V

Directiva de replicación: define el umbral de RPO, la retención de puntos de recuperación y la cadencia de las instantáneas coherentes con la aplicación. Por ejemplo, establezca el umbral de RPO en 15 minutos, conserve los puntos de recuperación durante 24 a 72 horas para una reversión a un momento dado y tome instantáneas coherentes con la aplicación cada 1 a 4 horas. Las directivas controlan la limitación del ancho de banda y la compresión; se puede habilitar la coherencia de múltiples VM para máquinas virtuales relacionadas para que sus puntos de recuperación se alineen.
Puntos de recuperación: ASR mantiene puntos de coherencia de bloqueo de forma continua y puntos adicionales coherentes con la aplicación cuando la inmovilización de VSS tiene éxito. La retención le permite seleccionar puntos anteriores para mitigar la corrupción lógica o el ransomware.
Conmutación por error de prueba: los simulacros no disruptivos validan los runbooks, el orden de arranque y las redes. Use una VNet aislada, proporcione valores de entrada de prueba (p. ej., IP de DNS) y asegúrese de que la resolución de nombres esté aislada. La replicación de producción continúa sin afectarse, y la limpieza elimina los artefactos de prueba después de la validación. Establezca la asignación de red y pruebe las asignaciones de NIC de antemano para evitar conflictos de IP.

Protección de VMware

Servidor de configuración: el dispositivo local que se registra en el Recovery Services vault, descubre el inventario de vCenter/ESXi, coordina la replicación e implementa los agentes de Mobility Service. Es el plano de control para la protección de VMware.
Servidor de procesos: generalmente coubicado con el servidor de configuración al principio; realiza el seguimiento de cambios, la compresión, el cifrado y la transferencia de datos a Azure. Se agregan servidores de procesos de escalabilidad horizontal para aumentar el rendimiento y para posicionar el ingreso de datos cerca de los hosts protegidos para minimizar la latencia.
Servidor de destino maestro: se utiliza para la conmutación por recuperación de Azure a VMware. Recibe los cambios replicados durante la reprotección y proporciona una zona de aterrizaje para que pueda restaurar las cargas de trabajo de vuelta a vSphere. Dimensione el almacenamiento para la tasa de escritura agregada durante la conmutación por recuperación y asegúrese de que el rendimiento de la red coincida con las ventanas de resincronización máxima.
Mobility Service: se instala en cada VM protegida para capturar los cambios en el disco. Mantenga actualizadas las credenciales o los mecanismos de inserción y supervise el estado del agente en el almacén.

Orquestación y coherencia

Planes de recuperación: runbooks declarativos para DR que definen agrupaciones, orden de arranque, pasos de aprobación manual y tareas de automatización. Use runbooks de Azure Automation para reconfigurar NSG, actualizar registros DNS, precalentar las cachés de las aplicaciones o ejecutar scripts de SQL. Asigne grupos lógicos como las capas «Datos», «App» y «Web», e inserte pausas para la validación.
Runbooks: automatizan tareas específicas del entorno, como cambiar los puntos de conexión del administrador de tráfico, escalar las dependencias de PaaS o deshabilitar la supervisión local durante la conmutación por error para reducir las alertas falsas. Parametrícelos para la conmutación por error de prueba frente a la de producción.
Grupos de coherencia de múltiples VM: habilítelos para las capas que comparten el mismo orden de escritura (p. ej., servidor de aplicaciones y escritor de registros de la base de datos). Esto garantiza un punto en el tiempo coherente en todas las VM; sacrifica rendimiento por corrección y debe limitarse a las VM que son verdaderamente interdependientes.

Impacto en RTO/RPO

RPO estricto: prefiera ASR con replicación agresiva e instantáneas coherentes con la aplicación, servidores de procesos dimensionados para el rendimiento y redes de replicación dedicadas. Para las bases de datos, considere la confirmación síncrona de Always On dentro de un área metropolitana.
RTO estricto: cree previamente las VNet, subredes y balanceadores de carga de destino; use planes de recuperación con automatización para eliminar los pasos manuales. Use conmutaciones por error de prueba con regularidad para establecer una línea base del RTO esperado.

Copia de seguridad y restauración: Azure Backup (MARS, MABS/DPM), almacenes y Windows Server Backup

Azure Backup proporciona protección a un momento dado (point-in-time) para cargas de trabajo locales (on-premises) y de Azure. Elija el tipo de agente y de almacén correctos según la carga de trabajo y las características.

Agente MARS (Microsoft Azure Recovery Services agent)

Política de copia de seguridad: Configure hasta tres copias de seguridad diarias con retención granular (diaria/semanal/mensual/anual) en el Recovery Services vault. Seleccione la redundancia de almacenamiento (LRS o GRS) y alinee la retención con el cumplimiento normativo mientras controla el crecimiento del almacén. Programe fuera de las horas pico de E/S y habilite la limitación de ancho de banda de red (network throttling) donde sea necesario.
Copia de seguridad del estado del sistema (System State): Compatible con MARS para Windows Server para proteger AD, el registro, COM+ y los archivos de arranque. Úselo para la recuperación de controladores de dominio (autoritativa/no autoritativa) o la reparación del sistema operativo sin una copia de seguridad completa a nivel de imagen.
Recuperación en línea: Restaure archivos/carpetas usando Examinar (Browse) o Buscar (Search). Instant Restore monta el punto de recuperación como un volumen para una copia rápida de archivos. Puede restaurar en la ruta original o en rutas alternativas, e incluso en otro servidor, utilizando las credenciales del almacén en el destino y autenticándose en el almacén.
Gestión de la frase de contraseña: El agente MARS utiliza una frase de contraseña de cifrado (AES-256) en poder del cliente, generada y almacenada localmente; Microsoft nunca la tiene. La pérdida de la frase de contraseña hace imposible la recuperación. Almacénela en una ubicación segura y respaldada (p. ej., un secreto de Key Vault sellado y respaldado por HSM con RBAC). Para rotarla, detenga la protección y vuelva a proteger con una nueva frase de contraseña. Habilite las características de eliminación temporal (soft delete) y PIN de seguridad en el almacén para protegerse contra detenciones/eliminaciones maliciosas.

Azure Backup con MABS/DPM e IaaS

Copia de seguridad de recuperación completa (BMR): Use Microsoft Azure Backup Server (MABS) o System Center DPM para capturar BMR para Windows Server. Esto permite reconstrucciones completas del servidor en hardware nuevo o en una VM arrancando WinRE o un medio de instalación y apuntando a la imagen BMR.
Recuperación en una ubicación alternativa: Para copias de seguridad de archivos/datos a través de MARS/MABS/DPM, restaure en una ruta alternativa o en un servidor diferente para evitar sobrescribir los datos de origen. Para las copias de seguridad de VM de IaaS de Azure (en un Recovery Services vault), restaure en una nueva VM, restaure discos en una VM existente o reemplace discos. Con Cross-Region Restore habilitado en el almacén, puede restaurar en la región emparejada para escenarios de interrupción regional.
SQL y SAP HANA en VM de Azure: Proteja con extensiones compatibles con la carga de trabajo (workload-aware) para lograr copias de seguridad coherentes con la aplicación y una restauración granular de la base de datos. Alinee la frecuencia de la copia de seguridad de registros con el RPO (p. ej., 15 minutos) y la retención con las necesidades de cumplimiento normativo.

Windows Server Backup (WSB)

Recuperación completa (Bare metal recovery): WSB puede capturar BMR (volúmenes del sistema y System State). Almacene en un disco o volumen dedicado para múltiples puntos de recuperación. Para destinos de recursos compartidos de red, solo se mantiene la última versión. Recupere arrancando desde un medio de Windows en WinRE y seleccionando “Recuperación de imagen del sistema” (System Image Recovery).
Copia de seguridad del estado del sistema (System State): Proporciona una recuperación rápida de AD DS, el registro y los archivos de arranque. Útil para controladores de dominio y servidores de configuración. Combine con copias de seguridad de archivos programadas para una cobertura más amplia.
Programación: Use la MMC de WSB o wbadmin para programar copias de seguridad diarias/por hora. Elija VSS Completa (Full) frente a Copia (Copy) dependiendo de si desea truncar los registros de la aplicación. Asegúrese de que las ventanas de copia de seguridad eviten las horas pico de E/S y verifique la integridad del catálogo (wbadmin get versions).

Tipos de almacén: Recovery Services vault frente a Backup vault

Recovery Services vault (RSV): El almacén tradicional para copias de seguridad de VM de Azure, copias de seguridad del agente MARS, MABS/DPM, copia de seguridad de Azure Files, SQL Server en VM de Azure y SAP HANA en VM de Azure. También aloja metadatos de ASR. Admite características como la eliminación temporal (soft delete), el PIN de seguridad y Cross-Region Restore (donde sea aplicable).
Backup vault: El almacén modernizado para ciertas cargas de trabajo nativas de Azure, como la copia de seguridad de Azure Disks y la copia de seguridad de Azure Blobs, y servidores flexibles de Azure Database for PostgreSQL. Utiliza Azure RBAC para la autorización del plano de administración, admite claves administradas por el cliente, opciones de inmutabilidad y se integra con Resource Guard para la protección de operaciones críticas. No aloja metadatos de ASR y, a día de hoy, no reemplaza al RSV para MARS/MABS/DPM ni para la mayoría de las copias de seguridad de VM de IaaS.

Alta disponibilidad a nivel de aplicación: SQL Always On y replicación de DFS

Algunas cargas de trabajo exigen una replicación nativa que complemente o reemplace la recuperación ante desastres (DR) a nivel de hipervisor, dependiendo del RTO/RPO.

Grupos de disponibilidad Always On (AGs)

Confirmación síncrona frente a asíncrona: La confirmación síncrona espera a que la réplica secundaria consolide el registro (harden the log) antes de confirmar la transacción en la principal, lo que proporciona una pérdida de datos casi nula (RPO bajo) a costa de la latencia y el rendimiento; utilícelo en enlaces de baja latencia (normalmente metropolitanos). La confirmación asíncrona no espera a la réplica secundaria, lo que permite un mayor rendimiento en enlaces WAN con una posible pérdida de datos durante la conmutación por error (RPO más alto).
Condiciones de conmutación por error automática: La conmutación por error automática requiere al menos dos réplicas de confirmación síncrona con la conmutación por error automática habilitada y sincronizadas. Windows Server Failover Clustering supervisa el estado de los nodos y servicios; la política flexible de conmutación por error de SQL Server define los niveles de condición de fallo (desde caídas de procesos hasta problemas graves de E/S). Se puede habilitar la detección del estado de la base de datos para forzar la conmutación por error cuando se sospecha de la base de datos principal. El diseño de quórum y testigo (witness) garantiza que se evite el “split-brain” (cerebro dividido); asegúrese de que las IP del DNS y del “listener” estén listas en el sitio de recuperación para una rápida reconexión del cliente.

Replicación de DFS (DFSR)

Grupos de replicación y conexiones: Un grupo de replicación es un conjunto de servidores que replican una o más carpetas replicadas. Las conexiones definen la topología (malla completa, hub-spoke) y la programación/limitación del ancho de banda. Utilice la topología hub-spoke para facilitar la escalabilidad y la resolución de problemas.
Área de ensayo (staging): DFSR utiliza un área de ensayo por cada carpeta replicada para almacenar los archivos delta para la Compresión Diferencial Remota (RDC). Dimensione el área de ensayo como mínimo al tamaño de su archivo más grande y, por lo general, a 1 o 2 veces la rotación diaria esperada (daily churn); un tamaño insuficiente provoca una limpieza y reintentos excesivos, lo que perjudica el RPO/RTO.
Resolución de conflictos: DFSR es multimaestro. Cuando se producen ediciones simultáneas, DFSR emplea vectores de versión y marcas de tiempo; el último en escribir gana (“last-writer wins”) y la copia perdedora se mueve a la carpeta ConflictAndDeleted (cuyo espacio se rige por una cuota). Para evitar conflictos iniciales durante la propagación inicial de datos (seeding), establezca un miembro como principal solo para la sincronización inicial. Para escenarios unidireccionales, utilice carpetas replicadas de solo lectura. Supervise los retrasos (backlogs) con dfsrdiag y ajuste las programaciones para cumplir con el RPO.

← Hyper-V · Todos los dominios · Gestión de identidades y acceso para entornos híbridos →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →