How to Set Up System State Backup and Bare Metal Recovery on Windows Server 2025

How to Set Up System State Backup and Bare Metal Recovery on Windows Server 2025

Protecting your Windows Server 2025 infrastructure goes far beyond copying files. System state backup captures the critical components that define your server’s identity — Active Directory databases, SYSVOL, the registry, COM+ class registration databases, certificate services data, and boot files. Without a valid system state backup, recovering a domain controller or certificate authority from a catastrophic failure becomes extraordinarily difficult. Bare metal recovery (BMR) takes this a step further, allowing you to restore a complete server — operating system, applications, and data — to new or repaired hardware with no prior OS installation required. This guide walks through configuring system state backups with wbadmin, building a Windows Server Backup policy, verifying backup integrity, and executing a full bare metal recovery using Windows Recovery Environment.

Prerequisites

• Windows Server 2025 (Standard or Datacenter) with the Windows Server Backup feature installed
• Administrator or Domain Admin privileges
• A backup target: local disk, external USB drive, or a UNC network share with write access
• Sufficient storage — system state backups for a domain controller are typically 20–60 GB depending on SYSVOL size
• Windows Server 2025 installation media or a WinPE USB drive for bare metal recovery
• For Active Directory: the NTDSUTIL tool available (included with AD DS role)

Step 1: Install the Windows Server Backup Feature

Windows Server Backup is an optional feature and must be installed before you can run wbadmin commands. Open an elevated PowerShell session and install the feature along with its command-line tools:

# Install Windows Server Backup feature and command-line tools
Install-WindowsFeature -Name Windows-Server-Backup -IncludeManagementTools

# Verify installation
Get-WindowsFeature -Name Windows-Server-Backup | Select-Object Name, InstallState

After installation, confirm that wbadmin.exe is available:

wbadmin get versions

If no backup versions exist yet, the command returns a message stating that no backups were found. That is expected at this stage.

Step 2: Perform a Manual System State Backup

The most straightforward way to capture system state is with wbadmin start systemstatebackup. For a domain controller, this includes NTDS.dit (the AD database), SYSVOL, the registry, and boot files. For a server running Active Directory Certificate Services, it also captures the CA database and private keys.

# Back up system state to a local volume (volume must not be the system volume)
wbadmin start systemstatebackup -backupTarget:E: -quiet

# Back up system state to a network share (requires credentials)
wbadmin start systemstatebackup `
    -backupTarget:"\fileserver01backupsdc01-systemstate" `
    -user:"CONTOSOBackupSvc" `
    -password:"P@ssw0rd!" `
    -quiet

The backup process runs in the foreground and displays progress. On a domain controller with a moderate-sized SYSVOL, this typically takes 15–45 minutes. The backup creates a versioned folder under the target path using a timestamp-based naming convention.

Step 3: Include System State in a Windows Server Backup Policy

For scheduled, recurring system state backups, configure a Windows Server Backup policy. This can be done through the GUI (Server Manager → Tools → Windows Server Backup) or entirely through PowerShell:

# Create a new backup policy
$Policy = New-WBPolicy

# Set the backup schedule — daily at 02:00 AM and 14:00 PM
$Schedule = New-WBSchedule -Schedule 02:00, 14:00
Set-WBSchedule -Policy $Policy -Schedule $Schedule

# Add system state to the policy
Add-WBSystemState -Policy $Policy

# Configure a local backup target (dedicated backup volume)
$BackupDisk = Get-WBDisk | Where-Object { $_.DiskNumber -eq 1 }
$BackupTarget = New-WBBackupTarget -Disk $BackupDisk -Label "SystemStateBackups" -PreserveExistingData $false
Add-WBBackupTarget -Policy $Policy -Target $BackupTarget

# Enable VSS full backup (critical for AD and Exchange)
Set-WBVssBackupOptions -Policy $Policy -VssCopyBackup

# Save the policy
Set-WBPolicy -Policy $Policy -Force

# Confirm the policy is active
Get-WBPolicy

The -VssCopyBackup option uses VSS copy backup mode, which does not clear application log files. For most server workloads this is correct; use -VssFullBackup only if you want Windows Server Backup to manage application log truncation.

Step 4: Verify System State Backup Versions

After backups run, verify that valid versions exist and check their contents before relying on them for recovery:

# List all available backup versions
wbadmin get versions

# List versions on a specific target
wbadmin get versions -backupTarget:"\fileserver01backupsdc01-systemstate" `
    -machine:DC01

# Sample output shows:
# Backup time: 5/17/2026 2:00 AM
# Backup target: Network Share labeled \fileserver01backupsdc01-systemstate
# Version identifier: 05/17/2026-02:00
# Can recover: Volume(s), File(s), Application(s), Bare metal recovery, System state

# Check items in a specific backup version
wbadmin get items -version:05/17/2026-02:00 `
    -backupTarget:"\fileserver01backupsdc01-systemstate"

Look for “System state” in the Can recover line. If it is missing, the backup did not complete the system state component successfully. Check the Windows Server Backup event log under Applications and Services Logs → Microsoft → Windows → Backup.

Step 5: Restore System State on a Running Server

If Active Directory or another system component becomes corrupted but the server is still bootable, restore system state without a full bare metal recovery:

# Restore system state from the most recent backup
wbadmin start systemstaterecovery `
    -version:05/17/2026-02:00 `
    -backupTarget:"\fileserver01backupsdc01-systemstate" `
    -machine:DC01 `
    -quiet

# For authoritative AD restore (restores deleted objects),
# boot into Directory Services Restore Mode (DSRM) first, then:
wbadmin start systemstaterecovery `
    -version:05/17/2026-02:00 `
    -authSysvol `
    -quiet

The -authSysvol flag marks SYSVOL as authoritative, causing it to replicate outward to other domain controllers — essential when recovering from accidental SYSVOL deletion.

Step 6: Perform a Bare Metal Recovery

Bare metal recovery restores the entire server to new hardware. Begin by booting from Windows Server 2025 installation media or a WinPE USB drive.

1. Boot from Windows Server 2025 ISO or USB
2. On the installation screen, click Repair your computer (bottom-left link)
3. Navigate to Troubleshoot → System Image Recovery
4. Windows RE will scan local drives for backup images. If the backup is on a network share, click Select a system image then Advanced → Search for a system image on the network and enter the UNC path
5. Select the backup version by date and time
6. On the Choose additional restore options screen:
   • Enable Format and repartition disks to wipe and recreate disk layout from the backup
   • Optionally click Exclude disks to protect secondary data drives from being repartitioned
   • Enable Install drivers if restoring to dissimilar hardware
7. Confirm and click Finish — the restore process begins, typically taking 30–90 minutes depending on backup size and network/disk speed

Step 7: Post-BMR Verification

After the server reboots following bare metal recovery, verify that all services and roles are functional:

# Check Active Directory replication health
repadmin /showrepl
repadmin /replsummary

# Verify SYSVOL is shared and replicating
net share | Select-String "SYSVOL|NETLOGON"

# Check that key AD-related services are running
Get-Service -Name "NTDS", "NETLOGON", "DNS", "Kerberos" |
    Select-Object Name, Status

# Check certificate services if ADCS is installed
Get-Service -Name "CertSvc" | Select-Object Name, Status

# Test domain connectivity
Test-ComputerSecureChannel -Verbose

# Check event logs for critical errors post-recovery
Get-WinEvent -LogName System -MaxEvents 50 |
    Where-Object { $_.LevelDisplayName -eq "Error" } |
    Select-Object TimeCreated, Id, Message

Step 8: Test Recovery in a Hyper-V Virtual Machine

Never wait for a production disaster to discover your backup is unrestorable. Test your BMR backups regularly by restoring to an isolated Hyper-V VM:

# Create an isolated test VM on the Hyper-V host
New-VM -Name "DC01-BMR-Test" `
    -MemoryStartupBytes 4GB `
    -Generation 2 `
    -NewVHDPath "D:VMsDC01-BMR-TestOS.vhdx" `
    -NewVHDSizeBytes 200GB `
    -SwitchName "Isolated-Test-vSwitch"

# Mount the Windows Server 2025 ISO as a DVD drive
Add-VMDvdDrive -VMName "DC01-BMR-Test" `
    -Path "D:ISOsWindowsServer2025.iso"

# Set boot order to DVD first
$VM = Get-VM -Name "DC01-BMR-Test"
$DVD = Get-VMDvdDrive -VM $VM
Set-VMFirmware -VM $VM -FirstBootDevice $DVD

# Start the VM and connect to VMConnect for the recovery wizard
Start-VM -Name "DC01-BMR-Test"
vmconnect.exe localhost "DC01-BMR-Test"

Run the bare metal recovery wizard inside the VM, pointing it to your network share backup. After recovery, verify that domain services start correctly. Document any issues and resolution steps so your runbook is accurate before a real disaster strikes.

Conclusion

System state backup and bare metal recovery are non-negotiable capabilities for any Windows Server 2025 environment hosting Active Directory, certificate services, or other stateful infrastructure roles. By combining wbadmin command-line backups with a structured Windows Server Backup policy, you ensure that recovery points exist on a predictable schedule. Verifying backup versions with wbadmin get versions and regularly testing restoration in an isolated Hyper-V VM transforms your backup strategy from a theoretical safety net into a proven, executable recovery process. When — not if — a hardware failure or corruption event occurs, the time invested in setting up and testing these procedures will be returned many times over.