Windows Server Backup — VSS, System State, and Bare-Metal Recovery
Windows Server Backup is the built-in backup role for Windows Server — here is how it works, what VSS gives you, the difference between system state and bare-metal recovery backups, and the wbadmin commands that actually matter in production.
Volume Shadow Copy Service — the Windows component that coordinates application-consistent snapshots. Without it, open files and databases back up in an inconsistent state.
A logical collection of critical OS components: the registry, boot files, COM+ database, and — on a domain controller — the Active Directory database and SYSVOL. Restores a server that is still bootable.
A full image backup of all critical volumes: OS, boot, and system state together. Lets you restore to completely bare hardware, including dissimilar hardware, from WinRE.
What Is Windows Server Backup?
Windows Server Backup is a built-in role available on Windows Server 2008 and later. Think of it as the replacement for NTBackup: it uses VSS to take point-in-time, application-consistent backups and writes them as VHD-format images to a local disk, external drive, or network share.
The role installs via Server Manager or PowerShell and provides both a MMC snap-in (wbadmin.msc) and a command-line tool (wbadmin.exe). The GUI and the command line are equivalent — everything the GUI can do, wbadmin can do, and wbadmin can be scripted.
How VSS Makes Backups Application-Consistent
A naive file copy of a running server produces a crash-consistent image at best: all the files are from the same moment, but databases with in-flight transactions, mail servers with open message queues, and AD with uncommitted writes may be in states they can technically recover from — but only if you are lucky. VSS solves this by coordinating between three components.
| Component | Role |
|---|---|
| VSS Requestor | The backup application (Windows Server Backup / wbadmin) that asks VSS to create a snapshot. |
| VSS Provider | The component that creates the actual shadow copy — either the built-in Windows software provider or a hardware provider from a SAN vendor. |
| VSS Writers | Application-specific components (SQL Writer, NTDS Writer for AD, Exchange Writer, etc.) that flush their in-memory state to disk and pause writes for the instant the snapshot is taken. The result is an application-consistent point in time. |
For a domain controller, the NTDS VSS Writer signals Active Directory to flush the database and log files before the snapshot, ensuring the AD database is in a clean, recoverable state. Without the writer, you get a crash-consistent copy that may not be bootable.
System State vs Bare-Metal Recovery — Which Do You Need?
This is the decision that matters before you configure anything. The two backup types have different scopes, different restore procedures, and different use cases.
| Dimension | System State | Bare Metal Recovery (BMR) |
|---|---|---|
| What it backs up | Registry, boot files, COM+ database, AD database + SYSVOL (on DCs) | Everything: OS volumes, applications, data, system state — all critical volumes |
| When to restore | Server is still bootable; specific OS components or AD are corrupt | Server will not boot, hardware failed, or ransomware encrypted the OS |
| Restore environment | From within the running OS (elevated command prompt) | Boot from Windows installation media → Repair your computer → WinRE |
| Dissimilar hardware | Not supported | Supported — drivers are injected during restore |
| BMR includes system state? | — | Yes — a BMR backup always includes system state |
| Typical size | A few GB (mostly the AD database on DCs) | Size of all critical volumes — often 30–100+ GB on production servers |
Installing the Role
# Install Windows Server Backup via PowerShell
Install-WindowsFeature Windows-Server-Backup
# Verify the installation and check the included tools
Get-WindowsFeature Windows-Server-Backup
# Import the PowerShell module (installed with the role)
Import-Module WindowsServerBackup
The role installs both wbadmin.exe and the Windows Server Backup MMC snap-in. After installation, a Windows Server Backup entry appears in Server Manager under Local Server.
Scripts / Commands
All wbadmin commands must be run from an elevated command prompt. Membership in the Backup Operators or Administrators group is required. Scheduling a backup requires Administrators membership specifically.
# --- CHECKING BACKUP STATUS ---
# List all available backups and their version identifiers
wbadmin get versions
# List backups stored at a specific target
wbadmin get versions -backuptarget:e:
# Check the status of a currently running backup job
wbadmin get status
# --- TAKING BACKUPS ---
# Take a system state backup to volume E:
wbadmin start systemstatebackup -backupTarget:e:
# Take a full backup of all critical volumes (bare-metal capable) to volume E:
wbadmin start backup -backupTarget:e: -allCritical -systemState -quiet
# Take a backup of specific volumes to a network share
# Use -user and -password if the share requires credentials
wbadmin start backup -backupTarget:\\backupserver\share -include:c:,d: -quiet
# Take a VSS copy backup (does not affect incremental/differential history of other tools)
wbadmin start backup -backupTarget:e: -allCritical -vssCopy
# --- RECOVERY ---
# Non-authoritative system state restore (server must be in Directory Services Restore Mode for DC restore)
# Replace the version identifier with the one from wbadmin get versions
wbadmin start systemstaterecovery -version:07/29/2026-18:00 -backupTarget:e: -quiet
# Bare-metal recovery — run this from WinRE (Windows Recovery Environment), not from the live OS
# Boot from installation media: Repair your computer > Troubleshoot > Advanced Options > Command Prompt
wbadmin start sysrecovery -version:07/29/2026-18:00 -backupTarget:e: -quiet
# --- SCHEDULED BACKUP ---
# Configure a daily scheduled backup to volume E: at 02:00 (runs via Task Scheduler)
wbadmin enable backup -addtarget:e: -schedule:02:00 -allCritical -systemState -quiet
# Disable the scheduled backup
wbadmin disable backup -quietwbadmin start sysrecovery (bare-metal restore) cannot run from within the live OS — the recovery process needs to overwrite volumes that are currently in use. You must boot into WinRE from Windows installation media to run it.
Domain Controller Considerations
Restoring a DC from a system state backup requires care because AD is a multi-master replicated database. An incorrect restore can introduce USN rollback or, in authoritative restore scenarios, reintroduce objects that were intentionally deleted.
| Restore Type | Use Case | How to Trigger |
|---|---|---|
| Non-authoritative | DC database corrupt or missing; AD from backup is used but immediately overwritten by replication from other DCs — the correct default | Boot into DSRM, run wbadmin start systemstaterecovery; let normal replication reconcile the database afterward |
| Authoritative | Accidentally deleted OU, user, or object needs to be restored as the authoritative version across all DCs | Non-authoritative restore first, then run ntdsutil to mark specific objects as authoritative before replication resumes |
bcdedit /set safeboot dsrepair and then shutdown /r /t 0; clear it afterward with bcdedit /deletevalue safeboot.
Backup Targets and Storage
Windows Server Backup supports three target types, each with different implications for retention and capacity.
| Target Type | Behaviour | Gotcha |
|---|---|---|
| Dedicated local volume | WSB manages the volume exclusively, creating a circular backup store — oldest backups are deleted automatically as space fills | The volume disappears from Windows Explorer once dedicated to WSB. Do not use a volume with other data. |
| Shared folder / UNC path | A single backup is kept; each new backup overwrites the previous one | If a backup fails mid-run, the previous backup is gone and the new one is incomplete — use dated subfolders to mitigate |
| Volume (non-dedicated) | Backup stored in WindowsImageBackup\<computername>\ folder; WSB does not manage retention automatically |
Storage fills indefinitely; you must manage old backups manually |
Troubleshooting Cheat Sheet
| Symptom | Likely Cause | Fix |
|---|---|---|
| Backup fails with “The request is not supported” | Target volume is too small or is the same volume being backed up | Use a separate volume for the backup target; ensure it has sufficient free space |
| VSS writer failure during backup | A VSS writer is in a failed or waiting state | Run vssadmin list writers to identify the failing writer; restart the associated service (e.g., restart ntds service for the NTDS Writer) |
wbadmin get versions shows no backups |
Backup catalog is corrupt or the wrong target is specified | Specify -backupTarget:<volume> explicitly; if the catalog is corrupt, run wbadmin restore catalog from a backup copy |
| System state restore fails on a DC | DC not booted into DSRM | Reboot into DSRM first: bcdedit /set safeboot dsrepair then shutdown /r /t 0 |
| Bare-metal restore cannot find backup on network share | WinRE network drivers missing or share credentials not provided | Add network drivers to WinRE manually, or temporarily copy the backup to a locally attached drive |
Final Thoughts
Windows Server Backup is not a replacement for a dedicated enterprise backup product in large environments. It has no deduplication, no centralised management across multiple servers, and its retention model for network share targets is crude. But it ships with every Windows Server licence, requires no agents, and produces VHD images that Hyper-V can mount directly — which makes it genuinely useful for small environments and as a secondary safety net for domain controllers specifically.
For domain controllers, a regular system state backup is non-negotiable. It is the only Microsoft-supported path to a non-authoritative or authoritative AD restore. The AD CS post covers a related dependency: certificates issued by an enterprise CA live in AD, so a corrupt CA database and a corrupt DC are both scenarios where system state backup is what recovers you.
wbadmin enable backup -allCritical -systemState and verify them regularly with wbadmin get versions. A backup you have never tested is a backup you cannot trust.
Next, we can look at the Windows Server print and document services role — print servers, driver isolation, and the surprisingly complex way Windows routes print jobs in an enterprise environment.