Windows Server Backup and Bare Metal Recovery with wbadmin

Windows Server ships with a full backup and bare metal recovery toolchain – Windows Server Backup (WSB) and wbadmin – that most operators ignore until they need it. The SERP for this topic is dominated by vendor content that uses wbadmin as a strawman before selling AOMEI, EaseUS, or Veeam. That framing is incomplete. For single-server SMB environments and homelabs, the built-in toolchain is capable, free, and enough – if you understand its constraints before you need to use it.

This article covers what windows server backup can actually do, what it cannot, and the exact commands to verify your backups before you’re staring at a failed restore.

Run all wbadmin commands from an elevated PowerShell or Command Prompt session. Most commands fail silently or return access errors when run without elevation.

What Windows Server Backup Actually Is

Windows Server Backup is a role service – not installed by default. It provides full server backups (all volumes), system state backups (registry, boot files, COM+, SYSVOL if DC), bare metal recovery (BMR) images bootable from WinRE, individual file and folder recovery, and application-consistent backups via VSS.

It is not a continuous data protection solution, not an agent-based backup for VMs, and not a replacement for Veeam or Azure Backup in multi-server environments. For a standalone member server or a single-role SMB box, it covers the real recovery scenarios: OS corruption, failed update, disk failure requiring BMR.

Install Windows Server Backup

WSB is not installed by default. The full feature reference is on Microsoft Learn – Windows Server Storage. Install via PowerShell:

Or via Server Manager: Add Roles and Features – Features – Windows Server Backup. Verify install:

Output should show [X] Windows Server Backup with Install State: Installed.

Understanding the Network Share Limitation

This is the constraint that trips up most operators.

A dedicated local backup disk gives Windows Server Backup more control over backup storage and version management. A remote shared folder is different. It is supported, but it should not be treated as a managed backup repository with predictable multi-version retention.

When you use a network share, verify what restore points actually exist:

If you expect seven restore points and wbadmin only shows one, your retention design is wrong even if the backup job reports Success.

Safe Retention Design for NAS Targets

If the backup target is a NAS, do not treat \\NAS\backups\SERVER01 as a complete retention strategy. Pair WSB with one of these patterns:

• NAS snapshots on the backup share – the most reliable option if your NAS supports it
• Dated subfolders per backup run – for example \\NAS\backups\SERVER01\2026-06-17
• Rotating backup targets – alternate between two share paths
• Scheduled replication from the WindowsImageBackup folder to immutable or offline storage

The key check: wbadmin get versions should show the restore points you expect. If it shows only one usable version, you do not have historical retention regardless of how many jobs have run.

Configuring Backups with wbadmin

One-time full backup to network share

-allCritical includes all volumes required for a BMR – the system volume, boot volume, and volumes containing system components. This is the flag you want for a machine you need to actually recover. It does not automatically include every data volume. If the server has application data on D: or E:, verify those volumes appear in wbadmin get items.

One-time full backup to local disk

Schedule daily backup to network share

For scheduled backups to a network share, use -addtarget (not -backupTarget):

The schedule is stored in Task Scheduler under \Microsoft\Windows\Backup. Use a dedicated backup service account. Do not paste real credentials into documentation, tickets, or screenshots.

System state only (for domain controllers)

System state includes: registry, boot files, COM+ Class Registration Database, certificate services database (if installed), and Active Directory (if DC). This is the minimum for a recoverable DC. For full forest recovery, you need more than system state – see the Active Directory Health Check and DCDIAG Explained articles for DC-specific context.

Verifying Backups Before You Need Them

The most common failure mode: operators configure backups and never verify them. They discover the backup is unusable during a restore attempt.

Check active or recent job status

Use this while a backup or recovery job is running, or immediately after, to confirm the operation completed without error.

List available backup versions

Output shows each backup version with: Backup Time, Backup Target, Version Identifier, Can Recover. Note the Version Identifier – you need it for restore commands. If wbadmin get versions returns nothing, the backup job is not completing. Check Task Scheduler (\Microsoft\Windows\Backup) and Event Log (Applications and Services Logs – Microsoft – Windows – Backup). The full wbadmin command reference on Microsoft Learn covers all flags and return codes.

List what is in a specific backup

Use the Version Identifier from wbadmin get versions. This shows every volume and application included. Verify that all volumes you need are present before closing the ticket.

Check recent job history via PowerShell

Output: last 5 backup jobs with start time, end time, and result (Success/Failed/Warning). Consistent warnings are worth investigating even when the job completes.

What Breaks: Common Backup Failures

Bare Metal Recovery: Step-by-Step

BMR restores the entire server – OS, applications, and data – from a WinRE environment. You need this when the OS volume is corrupted beyond repair, the system drive has failed and been replaced, or you are rebuilding after ransomware or catastrophic failure.

Before starting BMR, verify:

• Target disk is same size or larger than the original
• Backup is accessible – local disk, USB, or network path with credentials
• Boot media matches the OS version being restored (WS2022 media for WS2022 restore)

BMR procedure

1. Boot from Windows Server installation media (USB or ISO)
2. Language selection – Next
3. Click “Repair your computer” (bottom left) – do not click Install
4. Select Troubleshoot – System Image Recovery
5. Follow the wizard: select backup location – select version – confirm disk selection – restore

Drive letter trap in WinRE: The system volume is rarely assigned C: inside WinRE. Confirm volumes with diskpart - list volume before using bcdboot, DISM, or manual file paths. If you are specifying a network backup path during BMR, use the -machine: flag to ensure WSB finds the correct backup set.

Same-or-larger disk requirement: BMR writes the exact partition layout from the backup. If the target disk is smaller than the source – even by 1MB – the restore fails with a size mismatch error. This catches operators who replace a 500GB disk with “another 500GB disk” from a different manufacturer with slightly different reported geometry.

Version matching: You cannot restore a Windows Server 2022 BMR backup onto a machine booted from Windows Server 2019 media. OS versions must match.

If the BMR completes but the system fails to boot, see the Windows Server Boot Failure Recovery article – that scenario covers BCD repair after a restore.

Recovering Individual Files and Folders

When you do not need a full BMR – just specific files:

Or use the GUI: wbadmin – Recover – This Server – select version – Files and Folders – browse to items. Individual file recovery works from within the running OS – you do not need WinRE for this.

Recovering to Dissimilar Hardware

BMR to dissimilar hardware (different NIC, different storage controller) sometimes requires driver injection before the restored OS will boot. The restored image contains drivers from the original hardware. If the new hardware uses a different storage controller, Windows may fail to boot with an INACCESSIBLE_BOOT_DEVICE after BMR.

Mitigation – prepare before the original machine fails:

Keep the driver export with the backup. After BMR to dissimilar hardware, if boot fails, boot into WinRE and inject the missing drivers:

Driver injection can fix some storage and NIC problems, but it is not a guaranteed dissimilar hardware restore method. Test this path in a lab environment before relying on it. A VM test proves the backup is readable and the restore path works – it does not prove the image will boot cleanly on different physical storage or NIC hardware.

What Windows Server Backup Does Not Cover

Active Directory forest recovery: WSB backs up system state including AD. Recovering a failed forest – multiple DCs down, lingering objects, USN rollback – requires ntdsutil, DSRM boots, and a specific sequence. System state restore is one piece of AD recovery, not the complete procedure.

Granular SQL database recovery: WSB creates VSS-consistent SQL backups. Restoring individual databases requires SQL Server to be operational first, then restore via SQL Server tools. WSB BMR restores the files – it does not run SQL recovery automatically.

Granular Exchange mailbox recovery: WSB backs up Exchange VSS snapshots. Mailbox-level recovery requires mounting the database manually and using export tools.

WSB is the right tool when the restore target is simple and the recovery objective is modest. If the server runs multiple business-critical roles, a backup product with clearer retention, alerting, and tested application recovery is worth the investment.

Backup Verification Checklist

FAQ

Does Windows Server Backup support incremental backups?

Yes, but behavior depends on the backup target. Dedicated local backup disks support managed backup versions with block-level incrementals after the first full backup. Remote shared folders do not behave like a managed multi-version backup repository. If you back up to a NAS, verify retention with wbadmin get versions -backupTarget:\\NAS\path -machine:SERVER01.

Can I restore a Windows Server Backup to a smaller disk?

For bare metal recovery, assume no. The target disk must be the same size or larger than the original. Even small geometry differences between disks from different manufacturers can break a restore with a size mismatch error.

How do I verify a Windows Server Backup is working?

Start with wbadmin get versions, then run wbadmin get items -version: to confirm all volumes are present. Check Get-WBJob -Previous 5 for job history. After that, perform at least one test file restore. Listing a backup is not the same as proving the restore works.

Does Windows Server Backup work with network shares?

Yes, but network shares have important limitations around retention. If you back up to a NAS, design retention separately – NAS snapshots, dated folders, or another backup layer. Verify actual restore points with wbadmin get versions -backupTarget:\\NAS\path -machine:SERVER01.

Can I use Windows Server Backup for Active Directory?

You can back up system state including AD with wbadmin start systemstatebackup. This covers AD for single-DC or non-critical restore scenarios. Full forest recovery requires a more specific procedure involving DSRM and ntdsutil – system state backup is one input into that process.

What happens if a VSS writer fails during backup?

The backup either fails entirely or completes without that writer’s data, depending on which writer is affected. Check vssadmin list writers for any writer in state [7] Failed. Restart the associated service, verify the writer returns to Stable state, then re-run the backup job. Event ID 513 in the Application log contains writer-specific failure detail.

What is the difference between a full backup and a BMR backup?

A full backup includes all selected volumes. A BMR (bare metal recovery) backup is a full backup that specifically includes the system volume, boot volume, and all volumes required to restore and boot the OS – it is what -allCritical targets. BMR is what you need when the server cannot boot and you need to recover to a new or replacement disk from WinRE.