Introduction to Windows Server Backup

Windows Server Backup (WSB) is a built-in backup solution included with Windows Server 2022 at no additional cost. While it lacks some advanced features of third-party tools, it provides a reliable mechanism for protecting system state, critical volumes, bare metal recovery data, and individual files. Understanding how to install, configure, and use WSB is essential for any Windows Server administrator who needs a straightforward backup strategy without additional licensing costs.

WSB uses the Volume Shadow Copy Service (VSS) under the hood, which means it can capture application-consistent backups of running workloads including SQL Server, Active Directory, and Exchange when those VSS writers are properly registered. Backups can be written to local attached disks, network shares (UNC paths), or external USB drives. This article walks through every major aspect of Windows Server Backup on Windows Server 2022, from installation to recovery.

Installing the Windows Server Backup Feature

Windows Server Backup is not installed by default. You must add it as a Windows feature before use. You can install it via Server Manager or PowerShell. Using PowerShell is faster and scriptable for automated deployments.

To install via PowerShell, open an elevated PowerShell session and run the following command:

Install-WindowsFeature -Name Windows-Server-Backup -IncludeManagementTools

The -IncludeManagementTools parameter ensures that both the GUI snap-in (wbadmin.msc) and the PowerShell module are installed. After installation completes, verify by checking the feature state:

Get-WindowsFeature -Name Windows-Server-Backup

You should see Install State: Installed in the output. The Windows Server Backup PowerShell module is automatically imported once the feature is installed. You can list all available WSB cmdlets with:

Get-Command -Module WindowsServerBackup

Via Server Manager, navigate to Manage > Add Roles and Features, proceed to Features, check Windows Server Backup, and complete the wizard. No reboot is required for this feature.

Running a Manual Backup with wbadmin

The wbadmin command-line tool is the primary interface for running and managing backups from the command line. It predates the PowerShell module and remains fully functional in Windows Server 2022.

To start a one-time backup of the entire system (all volumes) to a network share:

wbadmin start backup -backupTarget:\fileserverbackups -include:C:,D: -allCritical -systemState -vssFull -quiet

Key parameters explained:

-backupTarget: The destination for the backup. Can be a UNC path (\servershare), a drive letter (D:), or a volume GUID. -include: Comma-separated list of volumes to include. -allCritical: Automatically includes all volumes required for a bare metal recovery, including the boot and system volumes. -systemState: Includes system state data (Active Directory, registry, SYSVOL, COM+ database, boot files). -vssFull: Performs a VSS full backup, which marks files as backed up and clears the archive bit. Use -vssCopy instead if you do not want to affect incremental backup tracking by other tools. -quiet: Suppresses confirmation prompts for scripting use.

To back up to a local disk that is dedicated for backup use only (WSB will format it and manage the storage):

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

Note that when using a local disk as a backup target, WSB takes exclusive ownership of that disk and formats it. Do not store other data on WSB-managed disks.

Creating a Backup Policy with PowerShell

For scheduled, recurring backups, the best approach is to define a backup policy (WBPolicy object) using PowerShell and then assign it as the scheduled backup configuration.

Step 1 — Create a new policy object:

$policy = New-WBPolicy

Step 2 — Add the volumes you want to back up. To add all critical volumes (boot, system, BCD store):

$criticalVolumes = Get-WBVolume -CriticalVolumes
Add-WBVolume -Policy $policy -Volume $criticalVolumes

To add a specific volume by drive letter:

$dataVolume = Get-WBVolume -VolumePath "D:"
Add-WBVolume -Policy $policy -Volume $dataVolume

Step 3 — Enable system state backup in the policy:

Add-WBSystemState -Policy $policy

Step 4 — Enable bare metal recovery (BMR) data in the policy:

Add-WBBareMetalRecovery -Policy $policy

Configuring Backup Targets

WSB supports three types of backup targets: local disk volumes, remote shared folders (network), and removable storage. Each is added to the policy differently.

Network share target:

$networkTarget = New-WBBackupTarget -NetworkPath "\nas01ServerBackupsWS2022-DC01" -Credential (Get-Credential)
Add-WBBackupTarget -Policy $policy -Target $networkTarget

Network backups keep only the most recent backup version. If you need multiple versions, use a local disk target instead.

Local disk target (dedicated backup disk):

$disk = Get-WBDisk | Where-Object { $_.DiskNumber -eq 1 }
$diskTarget = New-WBBackupTarget -Disk $disk -Label "BackupDisk01" -PreserveExistingBackups $false
Add-WBBackupTarget -Policy $policy -Target $diskTarget

Volume target (existing volume, not exclusive disk):

$volTarget = New-WBBackupTarget -VolumePath "E:"
Add-WBBackupTarget -Policy $policy -Target $volTarget

Volume targets allow other data to coexist on the volume, unlike dedicated disk targets.

Scheduling Backups

Once a policy is configured, attach a schedule to automate it. WSB supports one or more daily run times.

# Schedule backups at 02:00 AM and 02:00 PM daily
$times = [datetime]"02:00", [datetime]"14:00"
Set-WBSchedule -Policy $policy -Schedule $times

After defining the schedule, write the policy to the system to activate it:

Set-WBPolicy -Policy $policy -Force

To view the currently active scheduled backup policy:

Get-WBPolicy

To remove the current scheduled policy entirely (stops scheduled backups):

Remove-WBPolicy -Policy (Get-WBPolicy) -Force

Bare Metal Backup vs Critical Volumes vs System State

Understanding the difference between these backup types is critical for choosing the right recovery strategy.

Bare Metal Recovery (BMR) backup includes everything needed to restore the server to bare hardware — including the OS partition, boot configuration data, and all critical system volumes. This allows you to recover a completely failed server, including one with a replaced hard disk, from scratch using Windows Recovery Environment (WinRE). BMR backups implicitly include all critical volumes.

Critical Volumes backup includes the boot volume (typically C:), the system volume (where BCD resides), and the EFI System Partition on UEFI machines. This is a subset of BMR and allows volume-level restoration.

System State backup captures: Active Directory Domain Services database (NTDS.DIT) and log files, SYSVOL directory, Group Policy Objects, registry hives, COM+ class registration database, certificate services database (if installed), and boot files. System state backups are typically used to restore AD after accidental deletions or corruption without rebuilding the entire OS.

For domain controllers, always include both BMR and system state. For member servers, BMR alone is usually sufficient for disaster recovery.

Listing and Managing Backup Versions

To view all available backup versions stored in a target location:

wbadmin get versions

For a specific backup target on a network share:

wbadmin get versions -backupTarget:\nas01ServerBackupsWS2022-DC01 -machine:WS2022-DC01

The output lists each backup version with its identifier (VersionIdentifier), which is in the format MM/DD/YYYY-HH:MM. You use this identifier for recovery operations. The output also shows which types of recovery are available (bare metal, system state, volume, application).

To list items available within a specific backup version:

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

Performing a Recovery with wbadmin

WSB supports several recovery types. All recovery operations are performed with wbadmin start recovery.

File or folder recovery:

wbadmin start recovery -version:05/17/2026-02:00 -itemType:File -items:C:DataReports -recursive -overwrite:Overwrite -quiet

Volume recovery (restores an entire volume — target must be offline or a different volume):

wbadmin start recovery -version:05/17/2026-02:00 -itemType:Volume -items:C: -overwrite:Overwrite -quiet

System state recovery (used for AD restoration — server must be booted into DSRM for DC recovery):

wbadmin start systemstaterecovery -version:05/17/2026-02:00 -backupTarget:\nas01ServerBackupsWS2022-DC01 -quiet

Bare metal recovery is performed from Windows Recovery Environment (WinRE), not from within a running OS. Boot from Windows Server 2022 installation media, choose Repair your computer, then select Troubleshoot > System Image Recovery and point it to your backup location.

Monitoring Backup Health

To see the most recent backup summary and health status:

Get-WBSummary

This command returns details about the last backup: start time, end time, result (Success/Failed/Warning), number of bytes transferred, and any error messages. For scripting and alerting, check the LastBackupResultHR property — a value of 0 means success.

$summary = Get-WBSummary
if ($summary.LastBackupResultHR -ne 0) {
    Send-MailMessage -To "[email protected]" -From "[email protected]" -Subject "WSB Backup FAILED on $env:COMPUTERNAME" -Body $summary.LastBackupResultDetail -SmtpServer "smtp.example.com"
}

Windows Server Backup also logs events to the Windows event log under Applications and Services Logs > Microsoft > Windows > Backup. Event ID 4 indicates backup success; Event ID 5 indicates failure. You can query these with PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-Backup" | Select-Object -First 10 TimeCreated, Id, Message

Windows Server Backup Limitations

Before relying solely on WSB, understand its limitations in Windows Server 2022:

Single backup target for scheduled backups: The built-in scheduler only supports one backup destination at a time. Workaround: use Task Scheduler with wbadmin command-line to run multiple jobs to different targets.

Network share keeps only one version: When backing up to a UNC path, WSB overwrites the previous backup. You cannot keep multiple historical versions to a network share natively. Use a local/dedicated disk target for version retention.

No email notifications built-in: WSB does not send backup success/failure emails natively. Script this using PowerShell and Send-MailMessage as shown above, triggered by Task Scheduler after the backup job.

Maximum backup retention on local disk: Determined by available disk space. WSB automatically purges oldest backups when space runs low using a circular buffer strategy.

No deduplication of backup data: WSB stores backups as VHD files and uses block-level incremental logic, but does not perform true deduplication. Storage consumption grows steadily.

No application-aware recovery for all apps: While WSB integrates with VSS writers for SQL Server, Exchange, and AD, it does not provide granular application item recovery (e.g., individual mailboxes or SQL databases from the UI). For that, use application-specific backup tools or third-party solutions like Veeam.

No support for backing up to tape: WSB does not support tape drives as backup targets. Use Windows NT Backup compatibility tools or dedicated tape backup software.

Despite these limitations, Windows Server Backup is an excellent choice for small environments, secondary backup copies, and scenarios where budget constraints preclude commercial backup software. When combined with Azure Backup (MARS agent), it forms a solid two-tier backup strategy with both local and cloud copies.