I tested a bare-metal backup of a physical Windows Server 2022 domain controller created with Veeam Agent by restoring it as a Hyper-V VM on an isolated network. The first few boot attempts ended in CRITICAL_SERVICE_FAILED BSODs. After running CHKDSK from Windows Recovery Environment and allowing Windows to repair the disk, the VM booted normally. Active Directory Domain Services, DNS, and Netlogon all start successfully, and the restored controller appears healthy.
During the investigation, I checked the production server and found that chkdsk C: /scan reports NTFS corruption under C:Windows.old... and recommends chkdsk /spotfix. The C: volume is also marked dirty by fsutil dirty query C:, although there are no bad sectors. Active Directory itself appears healthy, and the environment has other functioning domain controllers. The restored VM now reports a clean filesystem after CHKDSK.
Does this point more toward an existing Windows/NTFS consistency issue on the source server than a problem with the Veeam restore? Would you be comfortable running chkdsk /spotfix on the production domain controller with verified backups and healthy partner controllers available, or would replacing the controller be the safer approach? I'm also interested in whether a crash-consistent backup could explain the initial boot failure.
4 Answers
The dirty volume and the initial CRITICAL_SERVICE_FAILED error strongly suggest the source filesystem was already inconsistent when the backup was created. The restore may simply have reproduced that state rather than introducing new corruption. A crash-consistent backup could also capture the disk while Windows was not fully clean, which explains why CHKDSK repaired the restored copy.
Driver injection is unlikely to explain this particular result if the restore was performed through Instant Recovery rather than the recovery-media bare-metal workflow. The more relevant clues are the dirty source volume and the fact that CHKDSK fixed the restored system. I’d document the recovery as successful, but repair or replace the source DC so future backups don’t continue capturing the same filesystem problem.
Since the restored VM is working and the source server has healthy domain controllers available, I’d usually replace the problematic DC instead of repairing it in place. Demote it cleanly, clean up metadata if necessary, reinstall Windows, and join the replacement to the domain. AD is multi-master, so rebuilding one controller is often safer and cleaner than taking a production DC offline for filesystem repairs.
If rebuilding the server isn’t feasible, running /spotfix during a planned maintenance window is generally reasonable after confirming the backups can actually be restored and that the other domain controllers are healthy. Expect downtime while the repair runs, and verify AD replication, DNS, and the event logs afterward. I’d still treat in-place repair as the second choice for a domain controller.
That would be my preference too. With verified backups and healthy replication partners, there’s little benefit in keeping a questionable system installation alive when a clean replacement is practical.