Introduction to System State Backup on Windows Server 2022

System state backup is one of the most critical recovery capabilities on Windows Server 2022. Unlike a full volume backup, a system state backup captures the essential components that define the server’s identity and role — Active Directory Domain Services, the registry, boot files, COM+ class registration databases, and more. Understanding what goes into a system state backup and how to restore it is a foundational skill for any Windows Server administrator. This guide walks through everything from identifying system state components to executing a complete bare metal recovery from the Windows Recovery Environment.

What Is Included in a System State Backup

The system state is not a single file — it is a collection of critical operating system components that must be backed up and restored together to maintain server consistency. On Windows Server 2022, the system state includes the following components regardless of installed roles:

Registry: The full Windows registry hive, including HKEY_LOCAL_MACHINE. This contains all hardware configuration, installed software settings, service configurations, and security policy data.

COM+ Class Registration Database: The registration data for all Component Object Model components, required for application services that depend on COM+.

Boot Files: The files in the system root that are required to start the operating system, including ntldr, bootmgr, BCD (Boot Configuration Data), and the system volume files.

Certificate Services Database: If Active Directory Certificate Services (AD CS) is installed, the CA database, CA keys, and configuration data are included in the system state. Without this data, your PKI infrastructure cannot be restored.

Active Directory Domain Services (AD DS): On domain controllers, the system state includes the NTDS.dit database (the Active Directory database), the SYSVOL shared folder (group policies and logon scripts), and the AD DS log files. The NTDS.dit file is typically located at C:WindowsNTDSntds.dit and can grow to many gigabytes on large domains.

SYSVOL: The SYSVOL replication folder contains Group Policy Objects and logon scripts. It is replicated between domain controllers via DFSR (Distributed File System Replication) on modern Windows Server environments. A system state backup captures a snapshot of SYSVOL at a point in time.

Note: System state backup does not capture application data, user home directories, or non-system volumes. For full server recovery you need either a bare metal backup or a combination of system state plus data backups.

Installing Windows Server Backup

Windows Server Backup (WSB) is the built-in backup solution on Windows Server 2022. It must be installed as a feature before you can use the wbadmin command-line tool.

Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools

Confirm the installation:

Get-WindowsFeature Windows-Server-Backup

Once installed, the wbadmin command becomes available in both Command Prompt and PowerShell. The Windows Server Backup MMC snap-in is also available under Administrative Tools.

Running a Manual System State Backup

The wbadmin start systemstatebackup command initiates a system state backup. You must specify a backup target, which must be a local volume (not a network share for system state backups — this is a key limitation).

wbadmin start systemstatebackup -backupTarget:E: -quiet

The -quiet switch suppresses confirmation prompts, which is required for scripted runs. Replace E: with the drive letter of your backup destination volume. The target volume cannot be the same volume that contains the system state data (typically C:).

To check the status of a running backup:

wbadmin get status

To list available backup versions:

wbadmin get versions -backupTarget:E:

The output will show version identifiers in the format MM/DD/YYYY-HH:MM which are used when restoring.

System state backups are stored in the WindowsImageBackup folder on the target volume. A typical system state backup for a domain controller ranges from 10 GB to 50 GB depending on the size of the NTDS database and installed roles.

Scheduling Automated System State Backups

For regular system state backups, you can create a scheduled task using PowerShell. The following script creates a daily scheduled task that runs a system state backup at 2:00 AM:

$action = New-ScheduledTaskAction -Execute "wbadmin.exe" `
    -Argument 'start systemstatebackup -backupTarget:E: -quiet'

$trigger = New-ScheduledTaskTrigger -Daily -At "02:00AM"

$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" `
    -LogonType ServiceAccount -RunLevel Highest

$settings = New-ScheduledTaskSettingsSet `
    -ExecutionTimeLimit (New-TimeSpan -Hours 4) `
    -MultipleInstances IgnoreNew

Register-ScheduledTask -TaskName "SystemStateBackup-Daily" `
    -Action $action `
    -Trigger $trigger `
    -Principal $principal `
    -Settings $settings `
    -Description "Daily system state backup to E drive"

Verify the task was created:

Get-ScheduledTask -TaskName "SystemStateBackup-Daily" | Select-Object TaskName, State

Bare Metal Backup with wbadmin

A bare metal backup goes further than a system state backup — it captures all critical volumes required to boot and run the server, including the system state, the operating system volume, and the EFI/boot partition. This enables a complete rebuild of the server onto new hardware or a new disk with no additional software needed.

wbadmin start backup -allCritical -systemState -backupTarget:E: -quiet

The -allCritical flag automatically includes all volumes that contain critical system components. The -systemState flag ensures the system state data is explicitly included in the backup catalog, making it restorable independently of the full volume restore.

To back up to a network share (bare metal backups do support UNC paths, unlike system state-only backups):

wbadmin start backup -allCritical -systemState `
    -backupTarget:\fileserverbackupsWS2022-DC01 `
    -user:DOMAINBackupSvcAccount `
    -password:SecurePassword123 `
    -quiet

For production environments, consider storing bare metal backups on a dedicated backup server or off-site location to protect against complete hardware failure or ransomware.

Understanding Windows Recovery Environment (WinRE)

The Windows Recovery Environment (WinRE) is a stripped-down version of Windows that boots from a hidden recovery partition or from installation media. It provides the tools needed to perform bare metal restores and system repairs without a functioning operating system.

To confirm WinRE is configured on your server:

reagentc /info

Expected output shows Windows RE status: Enabled and the location of the WinRE partition. If WinRE is disabled, enable it:

reagentc /enable

You can also access WinRE by booting from a Windows Server 2022 installation ISO and selecting “Repair your computer” instead of installing.

Performing a Bare Metal Restore from WinRE

To restore a server from a bare metal backup using WinRE:

1. Boot from Windows Server 2022 installation media or the WinRE partition. If using installation media, select your language then click Repair your computer at the bottom-left.

2. Navigate to Troubleshoot > System Image Recovery.

3. The wizard will scan for available backups. If the backup is on a local disk, it should be detected automatically. If on a network share, click Select a system image and provide the UNC path and credentials.

4. Select the backup version to restore from. You can restore the latest version or select a specific point-in-time backup.

5. On the “Choose additional restore options” screen, check Format and repartition disks if restoring to new or blank hardware. Leave unchecked if restoring to the same disk layout.

6. Confirm the restore and allow the process to complete. This can take anywhere from 20 minutes to several hours depending on backup size and storage speed.

After the restore completes, the server will reboot into the fully restored Windows Server 2022 environment.

Restoring System State in DSRM Mode

Restoring Active Directory system state on a domain controller requires the server to be in Directory Services Restore Mode (DSRM). This prevents AD DS from interfering with the restoration of the NTDS.dit database.

To boot into DSRM, run the following command and then restart:

bcdedit /set safeboot dsrepair

After restarting and entering DSRM (log in with the local Administrator DSRM password), run the system state restore:

wbadmin get versions -backupTarget:E:
wbadmin start systemstaterecovery -version:05/17/2026-02:00 -backupTarget:E: -quiet

Replace the version string with the actual version identifier from the get versions output. After the restore completes, remove the DSRM boot setting and reboot normally:

bcdedit /deletevalue safeboot

The domain controller will restart and replicate any changes from other domain controllers in the domain. If you are doing an authoritative restore (restoring deleted objects), you need to mark the restored AD partitions as authoritative using ntdsutil before rebooting:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "OU=DeletedUsers,DC=contoso,DC=com"
quit
quit

Testing Your Recovery Procedure

A backup that has never been tested is not a backup — it is a hope. Test recovery procedures regularly in a lab or isolated environment to verify that:

1. Backup jobs complete successfully and are logged in Event Viewer under Applications and Services Logs > Microsoft > Windows > Backup.

2. The backup catalog is readable from WinRE or a recovery system.

3. The system state restore completes without errors on a test machine.

4. DSRM restoration of a domain controller successfully brings up AD DS with correct data.

Check event log entries from the backup engine:

Get-WinEvent -LogName "Microsoft-Windows-Backup" | Select-Object -First 20 TimeCreated, LevelDisplayName, Message

Also verify the backup catalog directly:

wbadmin get items -version:05/17/2026-02:00 -backupTarget:E:

This command lists exactly what was captured in the specified backup version, allowing you to confirm system state components are present before you need them in an emergency.

System State Backup Limitations

There are important limitations to understand when planning a system state backup strategy on Windows Server 2022:

Local target only for system state: The wbadmin start systemstatebackup command requires a local volume as the backup target. It does not support UNC paths or network shares directly. If you need to back up to a network location, you must either use a bare metal backup (wbadmin start backup -allCritical -systemState) or mount a network share as a local drive using net use and then use subst or iSCSI to present it as a local volume.

Large AD databases: On environments with very large AD databases (10 GB or more), VSS-based system state backups through wbadmin can be slow and may not be suitable for tight backup windows. In these cases, consider using third-party solutions that support application-consistent AD backups with incremental capabilities.

No granular restore by default: System state restore is an all-or-nothing operation — you restore the entire system state to a point in time. For granular Active Directory object recovery (restoring individual deleted objects without a full DSRM restore), you need the Active Directory Recycle Bin feature enabled or a third-party AD recovery tool.

VSS writers required: System state backup relies on Volume Shadow Copy Service (VSS) writers for AD DS, Registry, and SYSVOL. If VSS writers are failing, system state backups will fail. Check VSS writer status with:

vssadmin list writers

Any writer showing a state other than [1] Stable or a last error other than No error must be investigated before relying on system state backups.

Conclusion

System state backup and bare metal recovery on Windows Server 2022 are essential disaster recovery capabilities that every administrator must understand and regularly test. Use wbadmin start systemstatebackup for lightweight daily AD DS protection, and wbadmin start backup -allCritical -systemState for complete server image backups that enable bare metal restoration. Always verify backup integrity, test restoration procedures in a lab environment, and monitor VSS writer health to ensure your backups will be available when needed most.