Problema

Al restaurar un controlador de dominio (Domain Controller) de Windows Server 2022 mediante una copia Bare Metal de Veeam, el sistema arranca una o varias veces con BSOD (CRITICAL_SERVICE_FAILED). Después de iniciar Windows RE y ejecutar CHKDSK, el equipo vuelve a iniciar sin problemas y los servicios de AD DS, DNS y Netlogon aparecen sanos.

El patrón que se repite en varios entornos es:

  • Una restauración Bare Metal (física o como VM) de un DC.
  • El primer arranque muestra una pantalla azul con el código de error.
  • El volumen del sistema está marcado como dirty (fsutil dirty query devuelve “Dirty”).
  • CHKDSK corrige la corrupción y el arranque vuelve a la normalidad.

Los síntomas no son exclusivos de Veeam; cualquier proceso que copie bloques de disco sin validar la integridad del sistema de archivos puede dejar el flag dirty y provocar fallos críticos de servicio al iniciar.

Causa

1. Inconsistencias de NTFS en la copia de seguridad

Los agentes de backup que operan a nivel de bloque pueden capturar datos mientras el volumen está en uso. Si el snapshot no se tomó en modo “crash‑consistent” o “application‑consistent”, el registro de cambios (USN Journal) y la tabla de metadatos de NTFS pueden quedar desincronizados. El flag dirty se establece cuando el sistema detecta que el volumen no se desmontó limpiamente.

2. Restauración a hardware distinto

Al pasar de un servidor físico a una VM, los controladores de disco cambian. El driver del controlador de disco del host original puede haber dejado referencias a estructuras de disco que ya no existen, provocando que el kernel de Windows intente iniciar servicios críticos sin los recursos esperados, lo que desencadena CRITICAL_SERVICE_FAILED.

3. Servicios críticos de AD dependientes del estado del volumen

El controlador de dominio carga varios servicios al arranque (NTDS, DNS, Netlogon). Si el sistema de archivos está marcado como dirty, el kernel bloquea la carga de algunos de estos servicios para evitar corrupción adicional, lo que se traduce en el BSOD mencionado.

4. Falta de sincronización de la base de datos de Active Directory

Durante la copia, la base de datos NTDS.dit puede quedar parcialmente escrita. Al restaurarse, el controlador intenta leer datos inconsistentes y el subsistema de seguridad falla, provocando el mismo código de error.

En la práctica, la causa más frecuente es la corrupción de NTFS detectada por el flag dirty, aunque la combinación de hardware distinto y servicios de AD aumenta la probabilidad de que el error se manifieste como BSOD.

Solución

Paso 1 – Verificar el estado del volumen antes de iniciar la VM

Antes de arrancar la máquina restaurada, abre la consola de Windows RE (WinPE) y ejecuta:

fsutil dirty query C:

Si el resultado es “Dirty”, no arranques directamente. El flag indica que el sistema necesita una revisión de disco.

Paso 2 – Ejecutar CHKDSK con opciones de reparación profunda

En la misma sesión de WinRE, lanza CHKDSK con los parámetros que forzan la reparación de metadatos y la re‑indexación de la tabla MFT:

chkdsk C: /scan /spotfix /perf
  • /scan realiza una inspección en línea sin desmontar el volumen (útil en WinRE).
  • /spotfix corrige los problemas encontrados sin necesidad de un reinicio adicional.
  • /perf habilita la optimización de rendimiento en discos SSD, pero no afecta a HDD.

Deja que CHKDSK finalice; puede tardar varios minutos en discos grandes.

Paso 3 – Reiniciar y validar los servicios críticos

Arranca la VM normalmente. Verifica que los servicios de AD DS, DNS y Netlogon estén en estado Running:

Get-Service -Name NTDS, DNS, Netlogon | Format-Table Name, Status

Si alguno sigue fallando, revisa el visor de eventos (eventvwr.msc) bajo System y Directory Service para identificar errores de replicación o de base de datos.

Paso 4 – Ejecutar un diagnóstico de integridad de AD

En el controlador restaurado, ejecuta:

dcdiag /test:Integrity /v /c /e
repadmin /replsummary

Estos comandos confirman que la base de datos de AD está coherente y que la replicación con los demás DC está funcionando.

Paso 5 – Considerar una copia de seguridad de nivel de imagen

Si la restauración frecuente genera flags dirty, evalúa cambiar la política de backup a image‑level con Veeam (Veeam Backup & Replication) o usar Veeam Agent en modo Volume Shadow Copy Service (VSS) para garantizar instantáneas consistentes.

Paso 6 – Programar CHKDSK periódico en producción

En un DC de producción, es seguro programar chkdsk /spotfix durante una ventana de mantenimiento, siempre que exista al menos un controlador adicional y que los backups estén verificados. El flag dirty no afecta la disponibilidad de los servicios mientras al menos un DC está activo.

Cuándo aplicar esta solución

  • Síntomas de arranque fallido: BSOD con CRITICAL_SERVICE_FAILED, pantalla azul repetida, o mensajes de “The volume is dirty”.
  • Flag dirty detectado: fsutil dirty query devuelve “Dirty” en el volumen del sistema.
  • Restauraciones Bare Metal: Después de copiar una imagen completa a hardware diferente (VM, nuevo servidor físico).
  • Entornos con varios DC: Cuando la replicación está disponible y se pueden tolerar breves interrupciones.

No aplica cuando:

  • El error ocurre en una máquina que no es controlador de dominio y los servicios críticos no dependen del estado del volumen.
  • La copia de seguridad se realizó con una herramienta que garantiza instantáneas VSS y el flag dirty nunca se marca.
  • El disco está físicamente dañado (errores de sectores malos) – en ese caso, la solución pasa por reemplazar el hardware antes de cualquier reparación lógica.

Código

# Verificar flag dirty
fsutil dirty query C:

# Reparar NTFS sin desmontar
chkdsk C: /scan /spotfix /perf

# Comprobar estado de servicios de AD
Get-Service -Name NTDS, DNS, Netlogon | Format-Table Name, Status

# Diagnóstico de integridad de AD
dcdiag /test:Integrity /v /c /e
repadmin /replsummary

Verificación

  1. Flag limpio: Ejecutar fsutil dirty query C: después de CHKDSK; debe devolver “Not Dirty”.
  2. Arranque sin BSOD: Reiniciar la VM y observar que Windows inicia sin pantalla azul.
  3. Servicios en ejecución: Confirmar que NTDS, DNS y Netlogon aparecen como “Running”.
  4. Sin errores críticos: Revisar el visor de eventos; no deben aparecer eventos críticos bajo System o Directory Service relacionados con corrupción de disco.
  5. Replicación saludable: repadmin /showrepl debe indicar “Last Successful Sync” reciente en todos los DC.

Notas adicionales

  • Backups verificados: Nunca confíes en una copia de seguridad sin haberla probado al menos una vez en un entorno aislado. La práctica de restaurar a una VM de pruebas ayuda a detectar flags dirty antes de tocar producción.
  • VSS vs. Crash‑consistent: Si el agente de backup no usa VSS, la probabilidad de flag dirty aumenta. Configura Veeam para que siempre cree snapshots VSS en controladores de dominio.
  • Plan de contingencia: Mantén al menos dos DC en línea. Si uno falla tras una restauración, el otro puede absorber la carga mientras se corrige el problema.
  • Monitoreo de discos: Implementa alertas de SMART y de eventos de NTFS (Event ID 55) para detectar signos de corrupción antes de que impacten en una restauración.
  • Documentación interna: Registra la fecha, versión del backup y los comandos ejecutados durante la recuperación. Facilita auditorías y reduce el tiempo de respuesta en futuros incidentes.