Windows Server ships a free full-server image backup tool. Most people never install it because it's an optional feature and the GUI is buried. The CLI is fine — wbadmin does block-level, VSS-consistent, bare-metal-capable images, no license, no agent.

It's not a replacement for offsite file backups. It's the thing that gets a dead box booting again in one restore, and it pairs well with restic for granular offsite.

TL;DR — install and take a bare-metal image of C: to E::

Install-WindowsFeature Windows-Server-Backup

wbadmin start backup -backupTarget:E: -include:C: -allCritical -vssFull -quiet

Details below.

Install the feature

It's not on by default. PowerShell:

Install-WindowsFeature Windows-Server-Backup -IncludeAllSubFeature

That gives you both wbadmin.exe and the WindowsServerBackup (WB*) PowerShell module. No reboot. Confirm:

Get-WindowsFeature Windows-Server-Backup
Get-Command -Module WindowsServerBackup

If you're still on a fresh box, do the initial setup checklist first — disk layout matters here.

One-off bare-metal image

wbadmin start backup -backupTarget:E: -include:C: -allCritical -vssFull -quiet

Breaking it down:

  • -allCritical is the important flag. It pulls in every volume holding components needed to boot and run the OS — the system reserved partition, EFI/boot, the OS volume, and the system state. Without it you get a file backup, not something you can bare-metal recover from. With it, the resulting image is bootable on replacement hardware.
  • -include:C: adds the C: data volume explicitly. -allCritical already grabs it on most layouts, but being explicit doesn't hurt.
  • -vssFull does a full VSS backup and resets each application's backup history (clears the archive bit / log truncation eligibility). Use it for a standalone server. If something else owns your backup chain (rare on a single box), use -vssCopy instead so you don't disturb its tracking.
  • -quiet suppresses the y/n prompt so it runs unattended.

VSS — the Volume Shadow Copy Service — is what makes this consistent. It snapshots the volume at a point in time so open files and running databases get captured in a coherent state instead of mid-write. SQL Server, AD (ntds.dit), the registry — all have VSS writers that flush before the snapshot. That's why wbadmin can image a live, running server without taking it down.

Scheduled backups

The classic CLI path:

wbadmin enable backup -addtarget:{disk-id} -schedule:02:00 -include:C: -allCritical -vssFull -quiet

Get the target disk identifier first:

wbadmin get disks

Use the disk identifier GUID, not a drive letter — a scheduled target gets dedicated (see the gotcha below), so it loses its letter anyway.

PowerShell WB* module path

The cmdlets are more readable and scriptable. Build a policy object, attach bare-metal recovery, set target and schedule, then commit:

$policy = New-WBPolicy

# capture everything needed for bare-metal recovery (critical volumes + system state)
Add-WBBareMetalRecovery -Policy $policy

# pick the dedicated backup disk
$disk = Get-WBDisk | Where-Object { $_.Properties -notcontains "ValidTarget" } | Select-Object -First 1
$target = New-WBBackupTarget -Disk $disk -Label "WSB"
Add-WBBackupTarget -Policy $policy -Target $target

# daily at 02:00
Set-WBSchedule -Policy $policy -Schedule ([datetime]"02:00")

# enable VSS full
Set-WBVssBackupOption -Policy $policy -VssFullBackup

# commit it as the active scheduled policy
Set-WBPolicy -Policy $policy

Check what's active and history:

Get-WBPolicy
Get-WBSummary

Target gotchas

This trips everyone up:

  • A scheduled disk target gets reformatted and dedicated. Windows takes the whole disk, wipes it, removes the drive letter, and uses it exclusively for backups. Do not point this at a disk with anything on it you want to keep. A one-off wbadmin start backup -backupTarget:E: does not dedicate — it just writes a WindowsImageBackup folder. The scheduled enable backup path dedicates.
  • The target can't be a volume you're backing up. You can't image C: onto C:. Separate physical disk, always.
  • A network share target keeps only the latest backup. -backupTarget:\\nas\backups works, but each run overwrites the previous one — no rotation, no version history on a share. A local dedicated disk keeps multiple versions until it fills, then rotates oldest-out automatically. If you need versioned offsite, that's restic's job, not this.

Bare-metal recovery

The whole point. Dead disk, new hardware, or a hosed OS:

  1. Boot the Windows Server installation media (same edition) or a WinRE recovery drive.
  2. Choose Repair your computer → Troubleshoot → System Image Recovery.
  3. Point it at the backup location (local disk or \\nas\backups). It finds the latest WindowsImageBackup, you confirm, it restores the critical volumes and reboots into a working server.

From a WinRE/WinPE command prompt you can drive it by hand. List what's available, then recover:

wbadmin get versions -backupTarget:E:
wbadmin start sysrecovery -version:06/04/2026-02:00 -backupTarget:E: -machine:SRV01 -recreateDisks -quiet

-recreateDisks repartitions to match the original layout — that's what makes "new bare disk" work.

Restore single items

You don't need bare-metal for "I deleted a file." From the running OS:

wbadmin get versions
wbadmin start recovery -version:06/04/2026-02:00 -items:C:\data\report.xlsx -itemtype:File -recoveryTarget:D:\restore -quiet

-itemtype:File for files/folders. -recoveryTarget keeps it out of harm's way instead of overwriting the live copy. There's -itemtype:Volume and -itemtype:App too (for VSS-aware apps like SQL).

Gotchas

  • VSS writer failures kill a backup silently-ish. If a writer is in a failed/timeout state, wbadmin either skips that component or errors out. Check writer health before trusting a scheduled run:

    vssadmin list writers

    Any writer not showing State: [1] Stable with Last error: No error is a problem. The usual fixes: free up disk space, restart the offending service (or its VSS provider), reboot. SQL and Hyper-V writers are the common offenders.

  • Retention is "until the disk is full." There's no -keep-daily 7. The dedicated disk holds as many full+incremental versions as fit, then auto-prunes oldest. Size the backup disk to at least 1.5× the source if you want meaningful history. Network share keeps exactly one. Plan accordingly.

  • Incrementals are block-level, fulls are periodic. After the first full, WSB does block-level incrementals via VSS, but it still rolls a periodic full. Don't be surprised when a "nightly" run occasionally takes much longer.

  • Encrypted source, encrypted target are independent. If C: is BitLocker-encrypted, the backup lands unencrypted on the target disk unless you BitLocker the backup disk too. A dedicated backup disk with no drive letter is awkward to encrypt — keep that disk physically controlled, or accept the restic path for encrypted offsite.

When to use which

  • wbadmin / WSB — full server image, disaster recovery, "get the box booting again." Fast restore, free, local. Weak on rotation and offsite.
  • restic — granular file-level, encrypted, deduplicated, offsite, real retention policies. Won't bare-metal a dead OS by itself.

Run both. wbadmin for the image, restic for the files and the offsite copy. They cover different failure modes.

Verify

A backup you haven't restored isn't a backup. Minimum checks:

wbadmin get versions
vssadmin list writers

Get-WBSummary | Format-List LastBackupResultHR, LastSuccessfulBackupTime, NextBackupTime

LastBackupResultHR should be 0. Anything else, dig into the Microsoft-Windows-Backup event log channel. Then actually do the drill: take a throwaway VM, restore the image into it from WinRE, confirm it boots. Once a quarter. The first time you find out your VSS writers were broken should not be during an outage.

Related posts