I tested a restore of a physical Windows Server 2022 domain controller backed up with Veeam Agent using a Full Computer bare-metal backup. I restored it as a Hyper-V VM on an isolated network.
On its first boot, the VM repeatedly crashed with CRITICAL_SERVICE_FAILED. After running CHKDSK from Windows Recovery Environment and allowing Windows to complete its repairs, it booted normally. Active Directory Domain Services, DNS, and Netlogon all start successfully, and the restored domain controller appears healthy.
While investigating, I checked the production server and found that chkdsk C: /scan reports NTFS corruption under C:Windows.old... and recommends chkdsk /spotfix. fsutil dirty query C: also reports that the C: volume is dirty, although there are no bad sectors. Active Directory itself is healthy, and the other domain controllers are available. The restored VM reports a clean filesystem after CHKDSK.
Does this look more like a pre-existing Windows or NTFS problem that was faithfully captured in the backup rather than a Veeam restore problem? With verified backups and other healthy domain controllers available, would you be comfortable running chkdsk /spotfix on the production DC, or would demoting and rebuilding the domain controller be the safer option?
3 Answers
Because Active Directory is multi-master and the other domain controllers are healthy, demoting and rebuilding this server is usually cleaner than repairing the system volume in place. Verify replication, transfer or seize any required roles, demote the problematic DC, clean up metadata if necessary, then reinstall and promote a fresh server. If rebuilding is impractical, /spotfix is generally a reasonable maintenance operation with verified backups and a recovery plan, but schedule it during downtime and be prepared for a longer repair.
The dirty-volume flag and the initial CRITICAL_SERVICE_FAILED error strongly suggest the source filesystem was already inconsistent when the backup was made. The restore may simply have reproduced that state rather than introducing corruption. Since the restored machine works after CHKDSK, I would treat the source filesystem as the main suspect. A backup can be application-consistent while still containing filesystem problems, so this is not necessarily evidence of a restore failure.
Also confirm how the restore was performed and whether any driver-injection or storage-controller settings were involved. Those can cause boot failures in some bare-metal recovery workflows. However, if this was an Instant Recovery-style restore and the source volume is visibly marked dirty, the NTFS inconsistency is the more convincing explanation. I would also verify that the backup job is producing the expected crash-consistent or application-consistent state rather than assuming the restore process caused the issue.
This test used Instant Recovery from the backup console rather than recovery media. The driver-injection option appears to belong to the recovery-media workflow, so it probably was not involved here.
The restore did eventually complete successfully, and the recovered DC is operating normally. My main concern is understanding the first-boot failure and whether future backups will keep capturing the dirty source volume until it is repaired.