Windows Server 2025 Backup and Bare Metal Recovery: Setup Guide

A backup you’ve never restored is still an open question. This guide sets up Windows Server Backup bare metal recovery on Windows Server 2025 from scratch. You’ll install the feature, run and schedule -allCritical backups, and check that they actually succeeded. Then you’ll prove the restore path works by rebuilding a server from the Windows Recovery Environment (WinRE).

The guide is also honest about where Windows Server Backup (WSB) stops. It allows one schedule per server, and it overwrites the previous backup each time it reuses the same network-share folder. It recovers only certain applications, as whole application data sets through their VSS writers, with no item-level application restores. And it can’t make an off-site copy on its own.

What Is Windows Server Backup?

Windows Server Backup is an optional feature included with every Windows Server 2025 license at no extra cost. It uses the Volume Shadow Copy Service (VSS) to take consistent snapshots of volumes. It writes the backup into a WindowsImageBackup folder on your target. You can drive it three ways: from an MMC console, from wbadmin.exe, or from the WindowsServerBackup PowerShell module.

What each backup type actually includes

Backup type	What’s in it	What you can restore from it
Bare metal recovery (BMR)	All critical volumes (EFI System Partition, C:, and on some layouts the Recovery partition) and boot configuration. The GUI’s Bare metal recovery item also selects System state; with wbadmin, add -systemState explicitly	A complete server onto empty or replacement disks, via WinRE
System state	Registry, COM+ class registration database, boot files, and certificate services. On domain controllers it also includes the Active Directory database and SYSVOL	Configuration-only rollback with wbadmin start systemstaterecovery
Volume / file	Any volumes you pick, such as D: data	Individual files, folders, or whole volumes
Full server (GUI)	Every volume on the server plus BMR and system state	Everything above

What -allCritical really means

A volume is “critical” if Windows needs it to boot or run. That covers the OS volume, the boot/EFI partition, and any volume that holds system-state components. For example, if the NTDS database or SYSVOL lives on D:, then D: becomes critical. If you’re not sure which volumes Windows treats as critical, run the one-off backup in Step 5 and read the volume list it prints before the copy starts.

The catch runs the other way too. A pure data volume like D:\Shares is not critical, so a BMR backup skips it. Rebuild the server from a BMR-only backup and your file shares won’t come back. Add data volumes explicitly with -include:D:, or use Full server.

When to use something else (or something extra)

WSB is a good last line of defense for one server or a handful. Reach for something else when you need any of these:

• Granular application restores. Think single Exchange mailboxes, SQL point-in-time recovery, or per-VM Hyper-V scheduling. Veeam Backup & Replication or System Center DPM handle these well.
• Built-in off-site retention. Azure Backup and the Microsoft Azure Backup Server (MABS) can send system state and BMR data to Azure. The trade-off is an ongoing subscription and storage cost.
• Compression and long version history on network targets. Imaging tools like Macrium Reflect Server or Acronis Cyber Protect cover this, but you pay a license fee per server.
• Central management across 10+ servers. WSB has no central console. Each server stands alone.

For a small fleet, the usual answer is WSB plus an off-site copy. That’s covered near the end of this guide.

Prerequisites

• Windows Server 2025 Standard or Datacenter, either Desktop Experience or Server Core
• A local Administrator account (or Backup Operators membership for running backups)
• A backup target sized at 1.5–2× the used space on everything you plan to protect (sizing steps below)
• WinRE enabled on the server (you’ll check this in Step 1)
• Windows Server 2025 install media (ISO or USB) that matches the server’s architecture, stored somewhere other than the server itself
• BitLocker recovery keys for any encrypted volumes, including an encrypted backup disk, stored offline
• A spare Hyper-V host or VM slot for test restores (strongly recommended)

Requirement	Details
OS version	Windows Server 2025 (build 26100) or later
Permissions	Local Administrators, or Backup Operators for running backups
Backup target	Dedicated internal or external disk (keeps versions), or an SMB share (a new backup to the same folder overwrites the previous one)
Recovery media	Windows Server 2025 ISO or bootable USB drive, 8 GB or larger
Network (share targets)	SMB 3.x access to the share. The account needs Change rights on the share and Modify rights in NTFS

Test environment: Windows Server 2025 Standard (build 26100.x) running as a Hyper-V Generation 2 VM with UEFI and Secure Boot. It has a 127 GB OS disk, a 200 GB data volume, and a dedicated 1 TB backup disk. A second run used an SMB share on a Synology NAS as the target.

Dedicated disk vs network share: pick deliberately

This is the biggest decision in the whole setup. Settle it before you install anything.

	Dedicated disk	Volume (existing drive letter)	Network share
Version history	Yes. Keeps many versions and prunes the oldest automatically	Yes, but it shares space with other data	No. A new backup to the same folder overwrites the previous one
Backup type	Block-level incremental after the first full backup	Incremental, with a performance hit on that volume	No incremental version chain to fall back on
Physically separate from server	Only if it’s external and rotated	No	Yes
Visible to ransomware on the host	Hidden (no drive letter), but still attached	Yes	Yes, if the credentials are reachable
BMR restore	Easiest option. WinRE finds it automatically	Works	Needs network drivers in WinRE

The trade-off is simple. A dedicated disk gives you history, but it’s physically attached to the server. A network share gets the data off the box, but a new backup to the same folder overwrites the previous one. If last night’s backup captured a corrupted database, or the run failed partway, you may have nothing older to fall back on. Microsoft’s own workaround is separate subfolders per backup, which needs twice the space.

For small shops, the best primary target is usually a dedicated disk. A 4 TB external USB 3.2 hard drive or an internal WD Red Plus works fine. Then layer an off-site copy on top.

Step-by-Step Guide

Step 1: Confirm WinRE Is Available

WinRE is the environment that runs the bare metal restore. If it’s disabled or its partition is missing, you find out at the worst possible moment. Check it now.

Open an elevated Command Prompt (right-click Start > Terminal (Admin)) and run:

reagentc /info

Expected output:

Windows Recovery Environment (Windows RE) and system reset configuration
Information:

Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: 3f1c2a9e-8b4d-11ef-9c2a-00155d0a1b02
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0

REAGENTC.EXE: Operation Successful.

If the status shows Disabled, enable it:

reagentc /enable

If reagentc /enable fails, winre.wim is usually missing from C:\Windows\System32\Recovery. You can copy it from install media, but don’t count on doing that during an outage. The install ISO can boot the same recovery tools, which is why having the media ready is a hard prerequisite.

Tip: Also note the boot mode now. Run msinfo32 and check BIOS Mode (UEFI or Legacy). A BMR restore must match the original boot mode.

Step 2: Size and Prepare the Backup Target

Find out how much data you’re protecting. Run this in elevated PowerShell:

# Lists lettered volumes with used and total space in GB
Get-Volume | Where-Object DriveLetter |
  Select-Object DriveLetter, FileSystemLabel,
    @{n='UsedGB';e={[math]::Round(($_.Size - $_.SizeRemaining)/1GB,1)}},
    @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}}

Expected output:

DriveLetter FileSystemLabel UsedGB SizeGB
———– ————— —— ——
C 38.4 126.3
D Data 142.7 200.0

Add up the used space on the volumes you’ll protect. Here that’s 181 GB. Size the target at 1.5–2× that total so a dedicated disk can hold a week or more of incremental versions. A 1 TB disk is plenty.

Next, prepare the target:

• Dedicated disk: Attach it and leave it alone. When you create the schedule, WSB wipes it, formats it, and removes its drive letter. Don’t use a disk that holds anything you want to keep.
• Network share: Create a share such as \\nas01\wsb-srv01, with one folder per server. Grant the backup account Change rights on the share and Modify rights in NTFS. WindowsImageBackup gets created at the root of that path. Keep it there, because WinRE looks for it at the share root.

Warning: The dedicated-disk option erases the entire disk, including every partition on it. Double-check the disk number before you confirm.

Step 3: Install the Windows Server Backup Feature

Option A: Server Manager

• Open Server Manager and click Manage > Add Roles and Features.
• Click Next until you reach Installation Type. Select Role-based or feature-based installation and click Next.
• Select your server from the pool and click Next.
• Skip Server Roles by clicking Next.
• On the Features page, check Windows Server Backup and click Next.
• Click Install, wait for “Installation succeeded,” then click Close.

Option B: PowerShell (works on Server Core)

Install-WindowsFeature Windows-Server-Backup

Expected output:

Success Restart Needed Exit Code Feature Result
——- ————– ——— ————–
True No Success {Windows Server Backup}

No reboot needed. To manage it remotely from another machine, add -IncludeManagementTools. On Server Core, you’ll use wbadmin and PowerShell only.

Step 4: Open the Windows Server Backup Console

Open Server Manager > Tools > Windows Server Backup, or run wbadmin.msc. Click Local Backup in the left pane.

On a fresh install, the center pane says no backup has been configured. The Actions pane on the right shows Backup Schedule, Backup Once, and Recover.

Step 5: Run a One-Off BMR Backup with wbadmin

Before you schedule anything, prove that the target and volume selection work. This is also the backup to run before any risky patch or in-place upgrade.

This example writes to an attached volume E:. Before you run it, confirm that E: really is the backup volume and not a data volume you’re about to fill. The target also can’t be one of the volumes included in the backup:

Get-Volume -DriveLetter E | Select-Object DriveLetter, FileSystemLabel, Size, SizeRemaining

Then run the backup from an elevated Terminal:

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

What each flag does:

• -backupTarget:E: sets the destination. It can be a drive letter, a volume GUID path, or a UNC path such as \\nas01\wsb-srv01.
• -allCritical includes every critical volume (the volumes that hold the operating system’s state). Microsoft describes it as the option to use when you’re creating a backup for bare metal recovery.
• -systemState adds system state to the backup. Don’t assume a critical-volume backup gives you a system-state restore point on its own; pass the flag so wbadmin start systemstaterecovery has something to work with.
• -include:D: adds the non-critical data volume. Leave it off if D: doesn’t exist.
• -vssFull runs a VSS full backup, which tells SQL Server and Exchange to truncate their logs. Swap it for -vssCopy (the wbadmin default) if another tool already runs full SQL backups. That way you don’t break that tool’s log chain.
• -quiet skips the confirmation prompt.

For a network share target, run the command as an account that already has access to the share. wbadmin uses the current user’s credentials by default.

Expected output (abbreviated):

wbadmin 1.0 – Backup command-line tool
(C) Copyright Microsoft Corporation. All rights reserved.

Retrieving volume information…
This will back up (EFI System Partition),(C:),Data(D:) to E:.
The backup operation to E: is starting.
Creating a shadow copy of the volumes specified for backup…
Creating a backup of volume (C:), copied (47%).
…
The backup operation successfully completed.
Summary of the backup operation:
——————

The backup of volume (EFI System Partition) completed successfully.
The backup of volume (C:) completed successfully.
The backup of volume Data(D:) completed successfully.
Log of files successfully backed up:
C:\Windows\Logs\WindowsBackup\Backup-24-09-2026_14-05-12.log

On the test VM, the first 181 GB backup took about 22 minutes to a local virtual disk. Treat that as one lab data point, not a benchmark: your time depends on source and target disk speed, file count, and whether the target is local or on the network. It’s still mostly a one-time cost on a dedicated disk, because later runs are incremental.

Step 6: (Alternative) Run a One-Off Backup with the Backup Once Wizard

The GUI does the same job and helps you learn the options.

• In the console, click Backup Once.
• Select Different options and click Next.
• On Select Backup Configuration, choose Full server (recommended) or Custom. With Custom, click Add Items and check Bare metal recovery. This auto-selects System state, the EFI System Partition, and C:. Add D: as well.

• Optionally click Advanced Settings > VSS Settings and choose VSS full Backup or VSS copy Backup. Use the same logic as the flags in Step 5.
• On Specify Destination Type, choose Local drives or Remote shared folder.

• Pick the destination. For a remote share, enter the UNC path and choose the access control option.
• Review the Confirmation page and click Backup. You can leave the window open or close it. The backup keeps running either way.

Step 7: Schedule Nightly Backups with the Backup Schedule Wizard

WSB supports exactly one schedule per server. Creating a new schedule replaces the old one. Plan a single job that covers BMR, system state, and data volumes.

• Click Backup Schedule > Next.
• Choose Full server (recommended), or Custom with Bare metal recovery plus your data volumes. Click Next.
• On Specify Backup Time, choose Once a day and set a time such as 10:00 PM. Pick More than once a day if you need tighter recovery points. Times come in 30-minute slots.

• On Specify Destination Type, pick Back up to a hard disk that is dedicated for backups (recommended). The other options are Back up to a volume and Back up to a shared network folder.
• Click Show All Available Disks, check your backup disk, and confirm the warning that it will be formatted.
• Click Finish. Formatting takes a few seconds. The disk then vanishes from File Explorer, which is expected.

Tip: You can select multiple dedicated disks in step 5. WSB writes to whichever one is attached. That’s a built-in way to rotate a second disk off-site.

Step 8: (Alternative) Schedule Nightly Backups with PowerShell

This approach suits Server Core, keeps a fleet consistent, and lets you keep the config in source control. First, find your target disk:

Get-WBDisk | Select-Object DiskNumber, DiskName, TotalSpace, Properties

Expected output:

DiskNumber DiskName TotalSpace Properties
———- ——– ———- ———-
0 Msft Virtual Disk 136365211648 Critical
1 Msft Virtual Disk 214748364800 ValidTarget
2 Msft Virtual Disk 1099511627776 ValidTarget

Disk 0 is critical, so it can’t be a target. Disk 2 is the 1 TB backup disk here, but disk numbers can change when disks are added or the server restarts. Cross-check the number against the disk’s size, serial number, and partition count before you pick it:

Get-Disk | Select-Object Number, FriendlyName, SerialNumber, Size, PartitionStyle, NumberOfPartitions

A brand-new backup disk usually shows RAW or zero partitions. If the disk you’re about to pick has partitions you don’t recognize, stop and find out what’s on it. Now build and apply the policy:

# Build an empty policy object in memory; nothing is saved until Set-WBPolicy
$policy = New-WBPolicy

# BMR = all critical volumes + boot configuration
Add-WBBareMetalRecovery -Policy $policy

# Add system state explicitly rather than assuming BMR covers it
Add-WBSystemState -Policy $policy

# Non-critical data volume that BMR would otherwise skip
$dataVol = Get-WBVolume -VolumePath "D:"
Add-WBVolume -Policy $policy -Volume $dataVol

# VSS full truncates SQL/Exchange logs; use -VssCopyBackup if another tool owns those logs
Set-WBVssBackupOption -Policy $policy -VssFullBackup

# Dedicated disk target (this disk WILL be formatted)
$disk = Get-WBDisk | Where-Object DiskNumber -eq 2
# Guard: stop unless disk 2 is the 1 TB disk you identified above
if (-not $disk -or $disk.TotalSpace -ne 1099511627776) { throw "Disk 2 is not the expected backup disk. Stop and re-check." }
$target = New-WBBackupTarget -Disk $disk -Label "WSB-SRV01"
Add-WBBackupTarget -Policy $policy -Target $target

# Run daily at 10:00 PM; pass several times ("12:00","22:00") for more than once a day
Set-WBSchedule -Policy $policy -Schedule 22:00

# Save and activate. This REPLACES any existing schedule on this server
Set-WBPolicy -Policy $policy

To use a network share instead, replace the dedicated disk target lines with these:

# Prompts for an account with Change (share) + Modify (NTFS) rights
$cred = Get-Credential
$target = New-WBBackupTarget -NetworkPath "\\nas01\wsb-srv01" -Credential $cred
Add-WBBackupTarget -Policy $policy -Target $target

Confirm that the policy is saved:

Get-WBPolicy

Expected output (abbreviated):

Schedule : {9/24/2026 10:00:00 PM}
BMR : True
SystemState : True
VolumesToBackup: {EFI System Partition, (C:), Data(D:)}
BackupTargets : {WSB-SRV01}

Warning: Set-WBPolicy overwrites the existing schedule without keeping a copy of it. To edit rather than replace, start from $policy = Get-WBPolicy -Editable.

Step 9: Verify Backups Actually Succeeded

A job that “ran” may still have failed. Check four places.

1. List the restore points:

wbadmin get versions

Expected output:

Backup time: 9/23/2026 10:00 PM
Backup location: Hard Disk labeled WSB-SRV01 2026_09_21 21:58 DISK_01
Version identifier: 09/24/2026-02:00
Can recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Snapshot ID: {5b2e0f3a-1c7d-4e9b-9a61-2d8f6c0e4b17}

The version identifier is in UTC, in MM/DD/YYYY-HH:MM format. Copy it exactly, because every restore command uses it. The key line is Can recover. If it doesn’t list Bare Metal Recovery, you don’t have a BMR backup.

2. Check what’s inside a version:

wbadmin get items -version:09/24/2026-02:00

This lists each volume with its size. It also lists any VSS-aware applications (such as Registry or AD) that were captured.

3. Check the last result from PowerShell:

Get-WBSummary

NextBackupTime : 9/24/2026 10:00:00 PM
NumberOfVersions : 3
LastSuccessfulBackupTime : 9/23/2026 10:00:00 PM
LastBackupTime : 9/23/2026 10:00:00 PM
LastBackupResultHR : 0
LastBackupResultDetailedHR : 0
CurrentOperationStatus : NoOperationInProgress

LastBackupResultHR : 0 means success. If LastBackupTime is newer than LastSuccessfulBackupTime, the most recent run failed. For per-job details, run this:

# -Previous 1 returns the most recent completed job
Get-WBJob -Previous 1

Check for JobState : Completed, HResult : 0, and an empty FailureLogPath.

This staleness check can run from Task Scheduler every morning:

$last = (Get-WBSummary).LastSuccessfulBackupTime
if ($last -lt (Get-Date).AddHours(-26)) {
    Write-EventLog -LogName Application -Source "WSB-Check" -EventId 9001 -EntryType Error `
      -Message "No successful Windows Server Backup since $last"
}

Register the event source once with New-EventLog -LogName Application -Source "WSB-Check". Then forward event 9001 to whatever alerting you already use.

4. Check Event Viewer. Open Event Viewer > Applications and Services Logs > Microsoft > Windows > Backup > Operational.

Event ID	Meaning	Action
1	Backup started	None
4	Backup completed successfully	Alert if this is missing for more than 26 hours
5, 9, 19, 20, 22	Backup failed (the cause is in the event text)	Alert
49, 50, 52	Target missing, inaccessible, or not found	Alert (often an unplugged USB disk or share credentials)

The simplest rule: alert on any Error-level event in this log, plus a missing event 4. To check from the shell:

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

Step 10: Restore Files, Folders, or a Volume

Practice a small restore now, before you need it for real.

GUI (Recover wizard):

• In the console, click Recover.
• Choose This server (or A backup stored on another location) and click Next.
• Pick a backup date from the calendar. Bold dates have backups.
• On Select Recovery Type, choose Files and folders, Volumes, Applications, or System state.

• Browse to the items you need.
• Choose Another location (for example D:\Restore) and Create copies so that you have both versions. Keep Restore access control list (ACL) permissions checked for shared data.
• Click Recover.

wbadmin:

# Restore one folder tree to an alternate path, keeping existing files intact
wbadmin start recovery -version:09/24/2026-02:00 -itemType:File -items:D:\Shares\Finance -recursive -recoveryTarget:D:\Restore -overwrite:CreateCopy

• -itemType:File sets the restore type. The other options are Volume and App.
• -recursive includes subfolders.
• -overwrite:CreateCopy never clobbers existing files. The other options are Overwrite and Skip.

To restore a whole data volume:

wbadmin start recovery -version:09/24/2026-02:00 -itemType:Volume -items:D:

Warning: A volume restore overwrites everything on the destination volume. Before you run it, confirm the version actually contains that volume with wbadmin get items -version:<id>, and check Get-Volume so you know which disk the drive letter maps to. Don’t point it at a volume with data you haven’t backed up.

For system state (say, rolling back a broken configuration), use wbadmin start systemstaterecovery -version:09/24/2026-02:00.

Domain controllers need more care. Boot into Directory Services Restore Mode (DSRM) first, and have the DSRM Administrator password ready. By default a system state restore on a DC is nonauthoritative: the DC goes back to its state at backup time, then normal replication from the other DCs overwrites it with every change made since. That’s what you want when one DC died and others are healthy. Restoring deleted objects so they win over replication is an authoritative restore, a separate step you must plan. The -authsysvol switch makes the SYSVOL part authoritative. Never restore a DC from a backup older than the forest’s tombstone lifetime (180 days by default on forests built on Windows Server 2003 SP2 or later). Read Microsoft’s nonauthoritative restore guidance before you rely on WSB for a DC.

Step 11: Get Ready for a Bare Metal Recovery

Collect these before disaster strikes. Keep them somewhere that won’t die with the server:

• A Windows Server 2025 ISO or bootable USB drive
• BitLocker recovery keys for the OS volume and any encrypted backup disk
• The server’s boot mode (UEFI or Legacy) and original OS disk size
• Storage and NIC drivers (.inf files on a USB stick) if the server uses RAID or a non-inbox controller
• Credentials for the share, if you back up to one

The best test is a real one. Once a quarter, restore the latest backup into an isolated Hyper-V VM on a spare host. Match the original boot mode: Gen 2 for UEFI, Gen 1 for Legacy. Give the VM a disk at least as large as the original. Give it no network connection, so the restored clone doesn’t collide with the live server’s name and domain identity.

Step 12: Perform the Bare Metal Recovery

• Attach the backup disk to the replacement hardware or VM. If you’re restoring from a share, have network access ready.
• Boot from the Windows Server 2025 install media. If the server still boots far enough to reach WinRE, you can use that instead.
• Choose your language and keyboard. On the setup options screen, click Repair my PC (older media calls it Repair your computer).
• Click Troubleshoot, then System Image Recovery. On some builds it sits under Advanced options.

• The Re-image your computer wizard opens:
  • Use the latest available system image (recommended) picks the newest version on the attached disk.
  • Select a system image lets you choose an older version. Click Advanced > Search for a system image on the network and enter \\nas01\wsb-srv01 for a share target. If no network adapter shows up, use Advanced > Install a driver first.
• On Choose additional restore options:
  • Check Format and repartition disks when restoring to new or blank disks. WSB recreates the original partition layout and erases the disks it uses. Before you tick it, confirm in WinRE’s Command Prompt (diskpart > list disk) which disk is which by size. If you can, physically disconnect any data disk you need to keep.
  • Use Exclude disks to protect any disk you don’t want touched, including the backup disk.
  • Use Install drivers for storage controllers that WinRE can’t see.
• Click Next > Finish, then confirm the warning that the disks will be formatted.
• Wait for the restore. The test VM restored 181 GB in about 25 minutes from a local virtual disk; physical hardware and network shares will differ. Then the machine reboots into the restored OS.

Command-line alternative from the WinRE Command Prompt. Drive letters differ in WinRE, so find the backup volume first with diskpart > list vol:

wbadmin get versions -backupTarget:F:
wbadmin get disks
wbadmin start sysrecovery -version:09/24/2026-02:00 -backupTarget:F: -machine:SRV01 -restoreAllVolumes -recreateDisks -excludeDisks:<disk identifiers to protect>

• -machine names the server whose backup you’re restoring. Microsoft’s syntax requires it whenever you pass -backupTarget.
• -restoreAllVolumes includes non-critical volumes such as D: if they were backed up. Without it, only critical volumes come back.
• -recreateDisks rebuilds the original disk and partition layout.
• -excludeDisks takes the disk identifiers from wbadmin get disks. Excluded disks aren’t partitioned or formatted.

Warning: -recreateDisks deletes all data on the volumes that host the operating system, and it can also delete data on data volumes. Format and repartition disks does the same in the wizard. List the disks first, exclude the backup disk and every disk you need to keep, and don’t add -quiet to this command, so you still get the confirmation prompt.

Dissimilar and smaller hardware caveats

• The target disk must be at least as large as the original disk. Used space doesn’t matter here. WSB recreates partitions at their original sizes. A 256 GB SSD can’t receive a backup of a 500 GB OS disk that’s 20% full. Shrink volumes on the source first if you plan to downsize.
• The boot mode must match. A UEFI/GPT backup needs a UEFI target, and Legacy/MBR needs Legacy. For Hyper-V, that means Gen 2 versus Gen 1.
• Different storage controllers may cause an INACCESSIBLE_BOOT_DEVICE error after restore. Inject drivers during the wizard. WSB offers no hardware-independent restore beyond that, and third-party imaging tools do this better.
• Physical-to-virtual restores usually work with Hyper-V Gen 2 targets. Afterwards, remove the old vendor agents and NIC teaming configuration.

Step 13: Check the Restored Server

After the first boot, confirm these:

# All volumes present at expected sizes
Get-Volume

# Encryption state (restored volumes may come back decrypted)
manage-bde -status

# WinRE still healthy on the restored disk
reagentc /info

# Schedule survived the restore
Get-WBSummary

Then check the event logs, services, and application health. Run a backup right away. On a domain member, the machine account password may be stale if the restore point is older than about 30 days. Test-ComputerSecureChannel -Repair fixes that.

Configuration

Setting	Options	Recommendation
Backup scope	Full server / Custom (BMR, System state, volumes)	Full server, or BMR plus every data volume
Target type	Dedicated disk / Volume / Network share	Dedicated disk as primary, with a share or rotated disk as secondary
VSS type	VSS full / VSS copy	Full if WSB is your only SQL/Exchange backup; Copy if another tool manages logs
Schedule	Once a day / More than once a day (30-minute slots)	Nightly outside business hours, with one consolidated job
Multiple dedicated disks	One or more disks in the schedule	Two disks, rotated weekly, with one kept off-site
Performance (GUI: Configure Performance Settings)	Normal / Faster / Custom	Faster for incrementals; it adds some I/O overhead during the backup window

Where WSB stops: layering an off-site copy (3-2-1)

The 3-2-1 rule says to keep three copies of your data, on two media types, with one copy off-site. WSB alone gets you two copies at best: production plus one local backup. These are practical ways to close the gap:

• Rotate two dedicated disks. Add both to the schedule and swap them weekly, keeping one off-site. It costs nothing beyond the second drive, and the offline disk is out of reach of ransomware.
• Back up to a NAS share, then replicate the NAS. Point WSB at an SMB share on a NAS (a Synology DS224+ is a common small-shop choice). Then use the NAS’s own snapshots and cloud sync for version history and an off-site copy. NAS snapshots also fix WSB’s “latest copy only” limit on shares.
• Add an immutable or cloud tier. Azure Backup (MARS agent) or a NAS-to-object-storage sync with object lock gives you the off-site copy WSB can’t create itself.

For retention, keep at least 7 daily versions locally, 4 weekly versions off-site, and a monthly copy for anything with compliance rules. On a dedicated disk, WSB prunes the oldest versions when space runs low. A bigger disk means a longer history. Put the server and backup NAS behind a UPS so a power cut mid-backup doesn’t corrupt the catalog.

Tips and Troubleshooting

Backup fails with a VSS writer error

Why it happens: A VSS writer (SQL, AD, Hyper-V, WMI, and others) is stuck in a failed or timed-out state. The snapshot can’t be made consistent.

Fix:

vssadmin list writers

Look for any writer where State isn’t [1] Stable or Last error isn’t No error. Restart the service behind that writer, then run the backup again.

Writer	Service to restart
System Writer	CryptSvc
WMI Writer	Winmgmt
SqlServerWriter	SQLWriter
Microsoft Hyper-V VSS Writer	vmms
IIS Metabase Writer	IISADMIN
Registry / ASR Writer	VSS

For example: Restart-Service CryptSvc. If writers keep failing, reboot the server and check the Application log for errors from the owning application.

Error 0x80780119: not enough disk space to create the volume shadow copy

Why it happens: Despite the wording, this usually points at a source volume. The target is rarely the problem. The usual culprit is a small Recovery or EFI partition without enough free space for shadow storage. VSS needs roughly 50 MB free on small volumes, or about 320 MB free on volumes larger than 500 MB.

Fix: Run vssadmin list shadowstorage and check free space with Get-Volume. Free up space on the partition in question, or extend it. If the Recovery partition is the problem, shrink C: slightly and extend the Recovery partition. Microsoft documents this process for WinRE partition resizing.

Backup target is too small

Why it happens: WSB doesn’t compress backups. A full server backup, or a first full backup to a share, needs roughly the entire used space of every protected volume.

Fix: Use a larger dedicated disk sized at 1.5–2× the used space, or remove non-essential volumes from the policy. On a dedicated disk, old versions are pruned automatically. On a volume target, you have to free space yourself.

Access denied (0x80070005) writing to the network share

Why it happens: The account saved in the schedule lacks share or NTFS rights, the password changed, or the path is wrong.

Fix: Grant the account Change rights on the share and Modify rights in NTFS. Test the path with Test-Path \\nas01\wsb-srv01 while running as that account. Then re-run the Backup Schedule wizard. Or rebuild the target with New-WBBackupTarget -NetworkPath ... -Credential (Get-Credential) and Set-WBPolicy. Use a dedicated service account with a documented password rotation process.

WinRE can’t find the backup on the network share

Why it happens: WinRE has no driver for the NIC, the credentials are wrong, or WindowsImageBackup isn’t at the root of the UNC path.

Fix: Use Install a driver to load the NIC driver, and re-enter the credentials in DOMAIN\user format. Point to the folder that directly contains WindowsImageBackup. That’s \\nas01\wsb-srv01, and never \\nas01\wsb-srv01\WindowsImageBackup.

“No disk that can be used for recreating volumes was found” during BMR

Why it happens: The target disk is smaller than the original, sits on a controller WinRE can’t see, or was excluded.

Fix: Use a disk at least as large as the original OS disk, load storage drivers through Install drivers, and check the Exclude disks list. In WinRE, run diskpart > list disk to confirm the disk is visible.

BitLocker recovery key prompt after restore

Why it happens: The TPM measurements no longer match because of new hardware, a new VM, or a changed boot configuration. Separately, if the backup disk itself is BitLocker-encrypted, WinRE needs its key before it can read the backup.

Fix: Keep the recovery keys offline, printed or in a password manager. Enter the key when prompted. After boot, run manage-bde -status. WSB stores volume data unencrypted in the backup, so restored volumes may come back decrypted. Re-enable protection with manage-bde -on C: -RecoveryPassword, and store the new key.

Server won’t boot after restoring to different hardware

Why it happens: There’s a boot mode mismatch (UEFI vs Legacy) or a missing storage driver.

Fix: Match the original boot mode. For Hyper-V, recreate the VM as the correct generation. Re-run the restore and inject storage drivers in the wizard.

The old schedule disappeared

Why it happens: WSB supports only one schedule per server. A new schedule replaces the old one, whether you create it in the wizard or with Set-WBPolicy.

Fix: Fold everything into one schedule. Use Get-WBPolicy -Editable to modify it. Use Backup Once or wbadmin start backup for ad hoc jobs.

Wrapping Up

You now have nightly BMR and data backups, a way to prove each one succeeded, and a tested path from a dead server back to a running one. The quarterly VM restore test is the part people skip. It’s also the only part that tells you whether any of this works.

My take: Windows Server Backup is a solid, free last line of defense for a small fleet. But it’s a local tool with one schedule, one copy on shares, and no off-site story of its own. Pair it with rotated disks or a replicated NAS, and treat any server without a tested restore as unprotected.

Step	Action	Applies To
1	Confirm WinRE with reagentc /info	Every server
2–3	Size the target and install Windows-Server-Backup	Every server
5–6	Run a one-off -allCritical backup	Before patches and upgrades
7–8	Schedule a nightly policy (GUI or New-WBPolicy)	Every server
9	Verify with wbadmin get versions, Get-WBSummary, and Event ID 4	Daily
10	Restore files or volumes	Accidental deletion, corruption
11–13	Bare metal recovery from WinRE and post-restore checks	Disk or hardware failure, quarterly test

Resources

• wbadmin command reference
• Back up a full server (Microsoft Learn)
• wbadmin start systemstaterecovery
• Back up system state and bare metal (System Center DPM 2025)
• Back up system state and BMR with Azure Backup Server
• Restore issue on Server 2025 (Microsoft Q&A)