Windows Server Backup in its default mode rereads the whole volume on every run. On our test server, the second backup took 710 seconds against 774 for the first, although only 512 MB had changed, and one radio button for incremental mode cut the next comparable run to 496 seconds. The bigger surprise came at the end: a bare metal recovery onto a blank disk worked in 7 minutes 21 seconds, but only after Windows refused the first attempt because the recovery environment had booted from a hard disk.
We ran the full cycle: install the feature, schedule wbadmin to a dedicated disk, run wbadmin start backup on demand, restore files, recover the whole server from WinRE and delete old backups. Every timing below comes from one Windows Server 2025 VM (build 26100.32230, measured October 2026 on Proxmox VE). Treat the seconds as numbers for this box and the ratios as the part that transfers to your hardware.
Windows Server Backup timings measured on Server 2025
Every operation we timed is in the table. The test server carried about 12.1 GB of Windows plus 2.01 GB of test data in C:\Data, and the backup target was a second 64 GB virtual disk dedicated to Windows Server Backup.
| Operation | Data changed or moved | Time | Target disk used after |
|---|---|---|---|
| Install the Windows-Server-Backup feature | none, no reboot needed | 158.4 s | n/a |
| Enable the 21:00 schedule (formats the disk) | none | 10 s | 0 GB |
| Backup 1, Normal performance (first full) | about 14.1 GB on C: | 773.9 s | 19.23 GB |
| Backup 2, Normal performance | +512 MB file, 20 files edited | 710.3 s | 22.86 GB |
| Backup 3, Normal performance | +2 GB restored copy | 780.8 s | 26.47 GB |
| Backup 4, Faster performance | +512 MB file, 20 files edited | 496.2 s | 25.20 GB |
| Restore one file to its original path | 21 bytes | 11.1 s | n/a |
| Restore a folder of 200 files elsewhere | 7.98 MB | 11.2 s | n/a |
| Restore one 2 GB file elsewhere | 2.00 GB | 110.6 s | n/a |
| Bare metal recovery onto a blank 64 GB disk | EFI, C: and recovery volumes | 441.3 s | n/a |
wbadmin delete backup -keepVersions:1 | 1 version removed | not timed | freed 2.25 GB |
Remove-WBBackupSet -KeepVersions 1 | 1 version removed | 0.2 s | freed 2.90 GB |
Three results matter more than the rest. The Normal setting made backup 2 only 8% faster than the first full run, because it rereads every block of C: and compares, so the time scales with volume size rather than with change. The Faster setting took the same 512 MB change down to 496.2 seconds, 30% under Normal, and the target grew by 1.63 GB instead of 3.63 GB. Restores are cheap by comparison: anything small finishes in about 11 seconds of fixed overhead, and large files move at roughly 18.5 MB/s on this storage, which is the number to plan a restore window with.
How the test box was set up
We cloned a Windows Server 2025 Datacenter template on Proxmox, the same kind of VM our Windows Server template guide for Proxmox builds, and renamed it BENCH01. Its disks are virtio-scsi devices. WinRE later needed the vioscsi driver the server already had from the VirtIO driver install:
- Compute: 2 vCPU, 6 GB RAM, UEFI with Secure Boot and a vTPM, so the EFI system partition is part of every backup.
- Disk 0 (64 GB): the system disk, laid out as EFI 100 MB, MSR, C: at 63.11 GB and a 789 MB recovery partition.
- Disk 1 (64 GB): the dedicated backup target, with room for the first full backup plus several versions of changes.
- Test data: 200 text reports, one config file and a 2 GB file of random bytes, so compression could not flatter the numbers.
Our Proxmox host is a shared node with other lab VMs on the same ZFS pool, so each run competed for the same disks. We did not repeat runs to average them; read differences under about 10% as noise and the 30% gap between Normal and Faster as real.
Step 1: Install the Windows Server Backup feature
Windows Server Backup is not installed by default on Server 2025, and the feature name Windows-Server-Backup covers both the wbadmin command line and the wbadmin.msc console. Open an elevated PowerShell window and install it with the management tools:
Install-WindowsFeature Windows-Server-Backup -IncludeManagementToolsOn the test box the install took 158.4 seconds and asked for no reboot:
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Windows Server Backup}Installing the feature also adds the WindowsServerBackup PowerShell module. Its Get-WBSummary cmdlet handles status checks later in this guide, and Remove-WBBackupSet deletes old versions.
Step 2: Schedule a backup to a dedicated disk
A dedicated disk keeps multiple versions and manages its own space, without sharing I/O with other data the way a volume target does. A network share is the weakest option, because each run overwrites the previous backup. Windows Server Backup formats the disk it is given and erases everything on it, so attach a disk with nothing you need. List the disks and copy the identifier of the empty one:
wbadmin get disksA fresh virtual disk shows a placeholder identifier and no volumes, which is the first sign of the problem described in the next section:
Disk name: QEMU QEMU HARDDISK SCSI Disk Device
Disk number: 1
Disk identifier: {00000000-0001-0000-0000-000000000000}
Total space: 64.00 GB
Used space : 0 bytes
Volumes: There are no volumes on the disk or Windows is unable to retrieve volume
information.Every zero in that identifier means Windows has never written a partition table to the disk, and wbadmin will not accept it in that state.
Error: “The specified backup location could not be found or is not a supported backup storage location”
Pointing wbadmin enable backup at that RAW disk fails with this exact message. The disk had never been initialized, so it had no partition table and only the placeholder ID shown above. Initializing it as GPT fixed it. Take the disk online and initialize it, with the disk number from wbadmin get disks:
Set-Disk -Number 1 -IsOffline $false
Initialize-Disk -Number 1 -PartitionStyle GPTRunning wbadmin get disks again now returns a real GUID for disk 1, {9611191e-fc9c-4c3b-bf6d-5f65e9a6bc6e} on our box. Create the schedule with that GUID. The flags below back up every critical volume (-allCritical, the switch that makes a backup usable for bare metal recovery) and system state at 21:00 daily:
wbadmin enable backup -addtarget:{9611191e-fc9c-4c3b-bf6d-5f65e9a6bc6e} -schedule:21:00 -allCritical -systemState -vssFull -quietTen seconds later, wbadmin printed the settings it saved, including the label it wrote to the disk:
Retrieving volume and component information...
The scheduled backup settings:
Bare metal recovery : Included
System state backup: Included
Volumes in backup: EFI(EFI System Partition) (100.00 MB),Windows(C:),(\\?\Volume{423abccb-91be-4f4b-8b4f-4fd83dcdd0b9}\)
Components in backup: (null)
Files excluded: None
Advanced settings: VSS Backup Option (FULL)
Location to store backup: QEMU QEMU HARDDISK SCSI Disk Device
Times of day to run backup: 21:00
Label the backup disk as BENCH01 2026_10_30 17:48 Disk_01.
This label identifies this backup disk during recovery.
The scheduled backup is enabled.Read two lines closely. “Bare metal recovery : Included” confirms -allCritical picked up the EFI partition and the hidden recovery volume as well as C:, which is what a restore onto a blank disk needs. -vssFull records the run as a full backup in the history of each VSS-aware application, and logs of earlier backups may be truncated, which matters for SQL Server or Exchange log chains; the Microsoft wbadmin enable backup reference warns against it when another backup product also protects the server, in which case leave the default -vssCopy. After this step the disk holds a 63.86 GB NTFS volume with no drive letter, so it no longer shows up in File Explorer.
Step 3: Run wbadmin start backup on demand
Waiting for 21:00 is not a test. Running wbadmin start backup with no parameters takes a one-off backup with the scheduled settings and target, which is the quickest way to prove the schedule works before you rely on it:
wbadmin start backup -quietOur first run took 773.9 seconds. Below is the tail of its output, after the per-percent progress lines:
Summary of the backup operation:
------------------
The backup operation successfully completed.
The backup of volume EFI(EFI System Partition) (100.00 MB) completed successfully.
The backup of volume Windows(C:) completed successfully.
The backup of volume (789.00 MB) completed successfully.
Log of files successfully backed up:
C:\WINDOWS\Logs\WindowsServerBackup\Backup-30-10-2026_17-49-21.logEvery restore command needs a version identifier, so list the versions next. Microsoft documents the identifier as GMT, while the “Backup time” line is local time. Our VM ran on UTC, so both read 17:49 and 18:04 here; on any other time zone they differ, so always copy the identifier line rather than building it from the clock:
wbadmin get versionsAfter the second backup the dedicated disk held two versions, both marked as able to recover files, volumes, applications, bare metal and system state:
The target shows as “1394/USB Disk” even though ours is a SCSI virtual disk, so do not read anything into that wording. Write down the volume GUID on that line, because it is how you point WinRE at this disk later, when the volume has no drive letter.
Step 4: Switch to faster incremental backups
Backup 2 took 710.3 seconds for a 512 MB change, and backup 3 took 780.8 seconds for 2 GB, because the default “Normal backup performance” reads the full volume and compares it with the last version. We changed it in the console: open wbadmin.msc, select Local Backup and click Configure Performance Settings in the Actions pane. This is the screen our timing table depends on:
- 1Normal backup performance
- 2Faster backup performance
- 3OK
- Normal backup performance: the default, where each run reads every block of each volume.
- Faster backup performance: tracks changed blocks between runs, which took the same 512 MB change from 710.3 s to 496.2 s.
- OK: saves the choice, and the next backup uses it.
Backup 4 also carried 2 GB more data than backup 2 (the restored copy in C:\Restore), so the 30% gain is, if anything, understated. The module has a Set-WBPerformanceConfiguration cmdlet for the same setting, which we did not run here. The dialog warns that change tracking might reduce disk throughput on the protected volumes and is not recommended for disk-intensive servers. That warning is fair. On a file server or a domain controller we would take the 30% shorter window. On a busy database host we would use Custom and keep that one volume on full backups.
After a few runs the console doubles as a quick health check. The Messages list showed each backup and file recovery with its result, and the status panel showed the next run at 9:00 PM:
That screenshot was taken after a deletion, which is why “Total backups” reads 1 copy while the Messages list still shows three backups.
Step 5: Restore files and folders with wbadmin
File restores read straight from the backup volume while the server stays up, and none of ours needed a reboot. We deleted C:\Data\configs\app.conf and 111 of the 200 reports, then brought the config file back to its original folder from the 18:04 version:
wbadmin start recovery -version:10/30/2026-18:04 -itemType:File -items:C:\Data\configs\app.conf -quietRestoring the 21-byte file took 11.1 seconds, almost all of it spent mounting the backup and reading its catalog:
Retrieving volume information...
You have chosen to recover the file(s) C:\Data\configs\app.conf from the
backup created on 10/30/2026 6:04 PM to C:\Data\configs\.
Preparing to recover files...
Successfully recovered C:\Data\configs\app.conf to C:\Data\configs\.
The recovery operation completed.
Summary of the recovery operation:
--------------------
Recovery of C:\Data\configs\app.conf to C:\Data\configs\ successfully completed.
Total bytes recovered: 21 bytes
Total files recovered: 1
Total files failed: 0For a folder, add -recursive. Sending it to -recoveryTarget instead of the original path lets you compare the old copy with the live one before you overwrite anything. Here the whole reports folder came back from the older 17:49 version:
wbadmin start recovery -version:10/30/2026-17:49 -itemType:File -items:C:\Data\reports -recoveryTarget:C:\Restore -recursive -quietAll 200 files landed in C:\Restore\reports in 11.2 seconds. The summary counts 201 because the folder itself is counted as an item:
Successfully recovered C:\Data\reports to C:\Restore\.
The recovery operation completed.
Summary of the recovery operation:
--------------------
Recovery of C:\Data\reports to C:\Restore\ successfully completed.
Total bytes recovered: 7.98 MB
Total files recovered: 201
Total files failed: 0The restored q3-report-2.txt ended without the “revised” line we had appended before backup 2, which confirms the older version was the one read. A single 2 GB file restored to C:\Restore took 110.6 seconds, and its SHA-256 matched the live file. When the original location already holds a file, -overwrite:Overwrite, CreateCopy or Skip decides what happens to it.
wbadmin get items -version:10/30/2026-18:04 lists everything a version can restore. On this server that was the EFI partition, C:, the 789 MB recovery volume and a Registry application component, which is system state. We did not run a system-state-only restore (wbadmin start systemstaterecovery) on this standalone server. The bare metal recovery below brings system state back as part of the image.
Step 6: Run a bare metal recovery onto a blank disk
Bare metal recovery is the test that proves a Windows Server backup is worth anything, so we ran it properly. We shut the server down, detached the original system disk, attached a new empty 64 GB disk in its place, and kept the backup disk attached. The restore runs from the Windows Recovery Environment, and the Microsoft wbadmin start sysrecovery reference notes that the command only works there. Before you rely on it, collect these from the running server:
- Version identifier: from
wbadmin get versions, here10/30/2026-18:48. - Backup volume GUID: from the “Backup target” line, because WinRE gave that volume no drive letter.
- Machine name: the hostname at backup time, here BENCH01.
- Storage driver: anything the recovery media lacks; for our virtio disks we mounted
Winre.wimwithdism /Mount-Imageand addedvioscsi.infwithdism /Add-Driver.
Our first attempt booted the WinRE image of the server itself (Winre.wim, copied out of the recovery partition and renamed boot.wim) from a small FAT32 disk. WinRE found both versions on the backup disk through the GUID path, then refused to rebuild the disks.
Error: “-recreateDisks is not available because Windows Recovery Environment is running from your hard disk”
WinRE returned this message in under a second, with exit code -2:
ERROR - WBADMIN START SYSRECOVERY -recreateDisks is not available because
Windows Recovery Environment is running from your hard disk. To use
WBADMIN START SYSRECOVERY -recreateDisks, run Windows Recovery
Environment from the Windows setup disc or Windows recovery disc.Between our two attempts the image was identical and only the boot device changed: the same boot.wim booted from a disk was refused, and booted from a CD-ROM it was accepted. It also rules out the recovery partition on the failed server, which loads WinRE from a disk, so a blank-disk restore needs separate boot media. In our lab that was the same WinRE image packed into a UEFI-bootable ISO and attached to the VM as a CD-ROM, and with it the identical command went through. On physical hardware the Server 2025 installation media is the usual choice; we did not test booting it from USB, or the repair screens of its setup wizard, in this lab.
From the WinRE command prompt, check that the backup is visible. Replace the GUID with the one from your own wbadmin get versions output:
wbadmin get versions -backupTarget:\\?\Volume{0543a18b-adb6-4ec0-9be0-8960e7e7621d}\Read the warning before the next command. Microsoft states that -recreateDisks deletes all data on volumes that host operating system components and might also delete data on data volumes. Our schedule backed up critical volumes only, so a data disk that survived the failure is not in the backup and could be wiped. Detach surviving data disks first, or list them with -excludeDisks, a comma-separated list of disk identifiers from wbadmin get disks (valid only together with -recreateDisks); our test had no data disks, so we used neither.
Then start the restore. -recreateDisks rebuilds the original partition layout on the empty disk and formats it, and -restoreAllVolumes also brings back non-critical volumes that were in the backup:
wbadmin start sysrecovery -version:10/30/2026-18:48 -backupTarget:\\?\Volume{0543a18b-adb6-4ec0-9be0-8960e7e7621d}\ -machine:BENCH01 -restoreAllVolumes -recreateDisks -quietWinRE ran on Pacific Standard Time (UTC-8) by default, so the local backup time reads 10:48 AM while the GMT identifier stays 18:48. In the lab the command ran unattended from a script inside the WinRE image, which stamped the start and end with the VM clock: 441.3 seconds for all three volumes:
The restored server booted from the formerly blank disk as BENCH01. Its partitions matched the original exactly (System 0.1 GB, Reserved 0.02 GB, C: 63.11 GB, Recovery 0.77 GB). C:\Data held all 104 files, and the SHA-256 of the newest file, written just before the backup, matched the value taken on the original disk. One detail to expect: the restored console reported the 6:23 PM backup as the last successful one, because its catalog was frozen inside the 18:48 snapshot while that backup was still running.
Our last backup ran in 496 seconds and the restore in 441, so on this storage a full rebuild takes about as long as one incremental backup, plus the time to boot the media. What makes it slow in practice is finding the version ID, the GUID and a driver while the server is down, which is why the list above is worth writing down today. If the disks of the server sit on a SAN, our iSCSI target and initiator guide covers presenting a LUN as the dedicated backup disk, and the same restore steps apply once WinRE can see it.
Step 7: Delete old Windows Server backups
On a dedicated disk you usually do not have to. Microsoft describes each version as a VSS shadow copy on the target, with the oldest dropped automatically when space runs short; our four runs never filled the 64 GB disk, so we did not see that rotation happen. Deleting by hand matters when you want space back now, or a fixed number of versions. There are three routes, and two of them worked on Server 2025:
wbadmin delete backup -keepVersions:1: worked on build 26100.32230 and freed 2.25 GB, although Microsoft Learn has no page for it.Remove-WBBackupSet -KeepVersions 1: the documented cmdlet, which finished in 0.2 seconds and freed 2.90 GB.wbadmin delete systemstatebackup: documented, but it removes system state backups only, so it does not shrink a volume-level backup set.
No module is needed for the wbadmin route, and it prints what it did:
wbadmin delete backup -keepVersions:1 -quietIt kept the newest version and removed the 17:49 one:
Enumerating backups...
Found 2 backups,
1 will be left after the delete operation.
Deleting backup version 10/30/2026-17:49 (1 out of 1)...
The operation to delete backups completed,
1 backups were deleted.We would script the PowerShell version. It is the path Microsoft documents and it is less likely to change. List the versions first, so you can see what will go:
Get-WBBackupSet | Format-Table VersionId, BackupTime -AutoSizeTwo versions were on the disk at that point:
VersionId BackupTime
--------- ----------
10/30/2026-18:04 10/30/2026 6:04:17 PM
10/30/2026-18:23 10/30/2026 6:23:47 PMRemove all but the newest. -Force skips the confirmation prompt, which matters in a scheduled task:
Remove-WBBackupSet -KeepVersions 1 -ForceRunning Get-WBBackupSet again returned only 10/30/2026-18:23, and used space on the target dropped from 26.47 GB to 23.57 GB. Keep at least two versions in normal operation. A single version means that a backup taken after silent corruption replaces your only clean copy.
What to watch after the first week
A schedule that ran once proves little; what fails later is space and silent errors. Get-WBSummary gives the state in one call and is easy to wire into monitoring. After our third backup it reported:
NextBackupTime : 10/30/2026 9:00:00 PM
NumberOfVersions : 2
LastSuccessfulBackupTime : 10/30/2026 6:23:47 PM
LastSuccessfulBackupTargetPath : \\?\Volume{0543a18b-adb6-4ec0-9be0-8960e7e7621d}
LastSuccessfulBackupTargetLabel : BENCH01 2026_10_30 17:48 Disk_01
LastBackupTime : 10/30/2026 6:23:47 PM
LastBackupTarget : BENCH01 2026_10_30 17:48 Disk_01
DetailedMessage :
LastBackupResultHR : 0
LastBackupResultDetailedHR : 0
CurrentOperationStatus : NoOperationInProgressAlert when LastBackupResultHR is not 0, or when LastSuccessfulBackupTime is older than about 26 hours on a daily schedule. The Microsoft-Windows-Backup event log carried these IDs during the test, and they are the ones to collect:
- Event 1: “The backup operation has started.” Its absence at 21:00 means the schedule never fired.
- Event 4: “The backup operation has finished successfully.” One per good run.
- Event 14: “The backup operation has completed.” Logged at the end of each of our runs, next to event 4.
- Event 24: “Backup started a fresh backup for volume.” We saw it twice, both times for the EFI partition.
Watch target growth per run as well. On this server a Normal-mode run added 3.63 GB for a 512 MB change, and a Faster-mode run added 1.63 GB for the same change. With 44.6 GB free after the first full backup, that is room for about 27 daily Faster-mode versions, or 12 in Normal mode, before the oldest have to go. If the server runs on a hypervisor, a host-level backup is a sensible second copy; our ActiveProtect and Proxmox Backup Server comparison covers two options. Keep a plain partition layout you can rebuild with diskpart when a restore goes sideways. The Windows Server 2025 install guide covers building the replacement server if you would rather start clean than restore.
