wbadmin Command in Windows: Versions, Recovery and Error Codes

wbadmin is the command line front end to Windows Server Backup. It creates one off and scheduled backups, restores volumes, files, applications and the system state, and reports on what has already been backed up. On a server with no third party backup agent it is the whole backup product, driven from an elevated prompt.

Most of the time you are not creating a backup with it. You are answering a question about one: what do we actually have, when did it run, can it restore a whole volume or only files, and why did last night fail. Four of the fifteen subcommands read without changing anything, a fifth reads when you give it no parameters, and those are the ones you reach for under pressure.

Microsoft documents every switch. What it does not spell out is the three places where reading the output goes wrong: the version identifier is not the timestamp printed above it, the output cannot be parsed the obvious way, and the failure code in the event log is printed in a different number base from the one you can search for. This page works through all three, with the parsing and the arithmetic measured rather than asserted.

Applies to: Windows Server 2016 / 2019 / 2022 / 2025

Quick answer

Four read only commands answer almost every question, and none of them changes anything. Run them in this order from an elevated prompt: the versions tell you what exists, the items tell you what is inside one of them, the status tells you whether something is running right now, and the schedule tells you whether tonight will happen.

rem 1. what backups exist, and the identifier every other command needs
wbadmin get versions

rem 2. what is inside one of them - the identifier is copied from step 1, exactly as printed
wbadmin get items -version:03/11/2026-09:07

rem 3. is a backup or recovery running right now
rem     this does NOT return until the job finishes, see example 6
wbadmin get status

rem 4. with no parameters, "enable backup" PRINTS the current schedule instead of setting one
wbadmin enable backup

Before the first example

Five things need to be true before the examples below behave as written. The reads are safe on a production server; the writes in examples 5 and 7 are not, so use a lab machine for those. The demo server throughout is SRV-PROD-01 and the demo backup target is drive H:.

1. An elevated prompt. Microsoft states the requirement on every single subcommand page: wbadmin must be run from an elevated command prompt. This check prints a line only when the token is elevated.

rem S-1-16-12288 is the High mandatory level SID - present only in an elevated token
whoami /groups | findstr /c:"S-1-16-12288"

2. Group membership. Administrators can do everything. Backup Operators can do everything except configure the schedule, which Microsoft restricts to Administrators. That split matters if you are handing the reads to a service desk account.

3. The feature installed. wbadmin.exe is not present until Windows Server Backup is added. Check first, because the error you get otherwise looks like a typo rather than a missing feature.

rem resolves the binary and proves the feature is on this box
where wbadmin

rem lists the subcommands THIS build actually supports, which is the real authority
wbadmin /?

4. The install command, if step 3 came back empty. The feature name is Windows-Server-Backup, and -IncludeManagementTools is what brings in the MMC snap in alongside the command line tool.

# check before installing - no reboot is needed for this feature
Get-WindowsFeature Windows-Server-Backup

# -IncludeManagementTools adds the wbadmin.msc snap-in as well as wbadmin.exe
Install-WindowsFeature -Name Windows-Server-Backup -IncludeManagementTools

5. Two escaping conventions. The loops below are written for an interactive prompt, so they use %a, and inside a .bat file the same loop needs %%a instead. One block, the second one in example 3, is written in file form for that reason and says so. Separately, delims= followed by a single space before the closing quote is deliberate: that is how you tell for /f that space is the only delimiter, and it is the whole trick in example 2.

Fifteen subcommands, and which of them only read

Microsoft publishes the same set of subcommands on two current pages, the wbadmin reference and the Windows Server Backup command reference, and both list fifteen. Unlike some legacy CMD tools there is no shorter modern list hiding a longer archived one, so the reference is complete. What the reference does not group for you is which of them are safe to run on a live server.

Two entries in that table are worth pausing on. start sysrecovery is documented as available only inside the Windows Recovery Environment, so it will not be in the list when you run wbadmin /? on a booted server. And enable backup is the one subcommand whose behaviour flips on argument count: Microsoft’s description is that with no parameters specified it displays the currently scheduled backup settings. Microsoft’s own event log guidance uses it exactly that way, as the check for whether a schedule exists at all.

The output has two timestamps and only one is an input

This is the single most useful thing to understand about wbadmin. Every recovery and every delete takes -version:, and the value has to come from get versions. The block below is a published capture of a single backup, from a Windows machine backing up to an external disk.

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

Backup time: 2/19/2017 8:31 PM
Backup target: 1394/USB Disk labeled Seagate Backup Plus Drive(E:)
Version identifier: 02/20/2017-01:31
Can recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Snapshot ID: {d4a62a80-ac6f-4aba-8886-6ba570c1284a}

Two banner lines come first, then the fields. Look at the Backup time line and the Version identifier line. The backup time says the 19th at 8:31 PM. The version identifier says the 20th at 01:31. Same backup, same minute, different day. One is local, the other is UTC, and the one you are allowed to type is the UTC one.

The offset is not a rounding artefact and it is not a one off. A separate published capture from a single run of get versions on one machine lists twenty one backups spanning July 2016 to May 2017. Reproducing the arithmetic across all twenty one pairs gives the same offset every time: exactly four hours, on the eight of them that ran under Eastern Standard Time as well as the thirteen that ran under daylight time.

The layout is also fixed width, which is easy to get wrong by hand. Microsoft documents the format as MM/DD/YYYY-HH:MM, and it means what it says: two digit month, two digit day, four digit year, 24 hour clock, two digit minute. Four plausible looking variants all fail that pattern.

Practical examples

1. Find out what you actually have

The problem: you have inherited SRV-PROD-01 and nobody can tell you whether its backups still work or what they cover.

The solution: one command lists every recoverable backup the local catalog knows about, and the Can recover line tells you whether a full volume restore is even on the table.

rem no parameters - reads the LOCAL catalog, touches nothing, safe on production
wbadmin get versions

rem redirect to a file rather than copying out of the console window
rem  the console buffer inserts a hard line break at its own width and splits long values
wbadmin get versions > C:\logs\wsb-versions.txt

If the command returns nothing at all, the catalog has no backups recorded. That is not the same as having no backups, and example 4 is the next step.

2. Pull the version identifier out for scripting

The problem: you want a batch file to act on the most recent backup, so it needs the version identifier as a variable, not as something you read off the screen.

The solution: filter to the identifier lines with findstr, then split on space rather than on the colon. The colon looks like the obvious delimiter and it is the wrong one, because the value contains a colon of its own.

This is the version that works. Token 3 is the value, because the label is two words and the first two space delimited tokens are Version and identifier:.

rem findstr /c: matches the literal string, so the banner lines never reach the loop
rem delims= followed by one space means space is the ONLY delimiter
rem tokens=3 lands on the value because "Version" and "identifier:" are tokens 1 and 2
for /f "tokens=3 delims= " %a in ('wbadmin get versions ^| findstr /c:"Version identifier"') do @echo %a

Against the capture shown earlier, that prints the identifier and nothing else.

02/20/2017-01:31

The reason to write it that way is that the obvious alternatives are wrong in ways that do not announce themselves. Reimplementing the for /f tokenizer and running all six candidates against the line Version identifier: 02/20/2017-01:31 gives this:

There is a second reason not to key a parser on anything except the identifier line. In one of the published captures, a single run of get versions on one machine labels some backups Backup target: and others Backup location:, depending on the media type. That capture holds two backups: filtering it on Backup target finds one of them and silently drops the other. Version identifier appears once per backup regardless.

3. See what is inside a version before you restore from it

The problem: a user wants a folder back from the Tuesday backup, and you need to know whether that volume was in it before you promise anything.

The solution: get items takes the identifier and lists the volumes, applications and components the version contains, with each volume’s size and what can be recovered from it.

rem -version is mandatory here, unlike get versions
wbadmin get items -version:03/11/2026-09:07

To inspect the most recent backup without reading the screen, put the loop from example 2 into a .bat file and let it overwrite a variable. It ends holding the last identifier printed, and the published capture that lists twenty one backups has them in ascending order, oldest first, so the last one is the newest. Note the doubled percent signs: this block is file form, not prompt form.

rem %%a because this is inside a .bat file - at the prompt it would be %a
rem the loop assigns on every line, so VER survives holding the LAST identifier
for /f "tokens=3 delims= " %%a in ('wbadmin get versions ^| findstr /c:"Version identifier"') do @set VER=%%a

rem prove you got something before using it, rather than after
rem  the parentheses matter: without them, exit /b would run either way
if not defined VER (
    echo No backups found in the catalog
    exit /b 1
)
wbadmin get items -version:%VER%

4. Read a backup disk when the catalog cannot help

The problem: the server will not boot, or it has been rebuilt, and you have the backup disk but no working catalog on the machine asking the question.

The solution: -backupTarget makes get versions read the media instead of the local catalog, and -machine picks one server out of a target holding several. Microsoft’s parameter table is explicit that -backupTarget is required to get information about a backup created from another computer.

rem ask the disk directly - works from WinRE, where the local catalog does not exist
wbadmin get versions -backupTarget:H:

rem one share holding several servers: -machine is what disambiguates
wbadmin get versions -backupTarget:\\NAS01\backups -machine:SRV-PROD-01

rem a dedicated backup disk usually has no drive letter, so address it by volume GUID
rem  mountvol with no arguments lists every volume and its mount points
mountvol

If the catalog on a working server is the thing that is broken, restore catalog rebuilds it from the media, and delete catalog is the last resort. Microsoft’s wording on the difference is worth keeping straight: use delete catalog only if the catalog is corrupted and you have no backups stored elsewhere to restore it from, and after deleting, create a new backup.

rem rebuild the local catalog from the media - the fix you try first
wbadmin restore catalog -backupTarget:H:

rem only when the media is also gone. after this, take a fresh backup immediately
wbadmin delete catalog

5. Run a one time backup, and know which kind you got

The problem: you need a backup right now, before a patch window, and you want it to be a usable base for what comes after.

The solution: start backup with -allCritical covers every volume holding operating system state, which is what bare metal recovery needs. The part that catches people is the VSS mode, which has a default and the default is not the obvious one.

rem -allCritical covers every volume holding OS state - required for bare metal recovery
rem -quiet suppresses the confirmation prompt, which is what makes this scriptable
rem -vssFull is explicit on purpose: without it you get -vssCopy, see the callout
wbadmin start backup -backupTarget:H: -allCritical -vssFull -quiet

rem system state only. this subcommand takes exactly two parameters and nothing else
wbadmin start systemstatebackup -backupTarget:H: -quiet

Two more documented constraints belong with this example. The target volume for a critical volume backup can be a local drive but it cannot be one of the volumes being backed up. And on a remote share, backing the same computer up to the same folder overwrites the previous backup, with the failure case Microsoft spells out plainly: if the backup fails you can end up with no backup at all, because the old one was overwritten and the new one is not usable. Their recommendation is subfolders per backup, which needs twice the space.

6. Watch a running job, and stop one

The problem: a backup has been running for three hours and you want to know whether it is progressing or wedged, from a session you can close.

The solution: get status attaches to the job. It is worth being clear about what that means, because the name suggests a snapshot and it is not one. Microsoft states that the command does not stop until the backup or recovery operation is finished, and that it continues to run even if you close the command window.

rem this BLOCKS. it returns when the job ends, not when it has told you the status
wbadmin get status

rem cancel the running job. there is no resume - a cancelled job restarts from zero
wbadmin stop job -quiet

If you want a status you can poll rather than one that blocks, the PowerShell side has Get-WBJob, which returns and lets your loop decide when to ask again. That is covered in the cross shell section below.

7. Prune system state backups without deleting the wrong ones

The problem: the backup volume is full, and the weekly system state backups have been accumulating for two years.

The solution: delete systemstatebackup with -keepVersions keeps a count and drops the rest. Its three selectors are mutually exclusive and Microsoft says so directly: specify only one of -keepVersions, -version or -deleteOldest.

rem keep the three newest system state backups, delete everything older
rem  -keepVersions:0 would delete ALL of them, which is a documented value not a guard
wbadmin delete systemstatebackup -keepVersions:3

rem drop exactly one, by identifier, taken verbatim from get versions
wbadmin delete systemstatebackup -version:03/11/2026-09:07

rem one at a time, oldest first, on a specific target
wbadmin delete systemstatebackup -backupTarget:H:\ -deleteOldest

Why last night failed: the same code in two number bases

When a backup fails, Windows Server Backup writes event 517 to the Application log with source Microsoft-Windows-Backup. Microsoft’s support article on a failed system state backup reproduces the event, and the shape is the point: the error code in the message text is decimal.

Log Name: Application
Source: Microsoft-Windows-Backup
Event ID: 517
Level: Error
Description:
Backup started at '<DateTime>' failed with following error code '2155348226'
(System writer is not found in the backup.). Please rerun backup once issue is resolved.

Searching for 2155348226 is close to useless. Searching for the same number in hexadecimal finds the fix. The conversion is the step, and it is worth doing in a way that cannot mislead you.

# the literal is already Int64 in PowerShell, so X8 formats it correctly
'0x{0:X8}' -f 2155348226          # returns 0x80780102

# and back, for a code the GUI showed you in hex
[uint32]'0x807800A1'             # returns 2155348129

That conversion is what connects the two halves of Microsoft’s own documentation. Measured in PowerShell 7.4.6, three pairs line up exactly.

The facility field, bits 16 to 26 of the HRESULT, is the quickest triage you have. A code in the 0x8078 range came from Windows Server Backup itself. Anything else came from a layer underneath it, and the third row is the case that catches people: 0x800423F4 looks like a backup error because the backup is what reported it, and it is a VSS error.

Even inside the 0x8078 range the facility is not the whole story. Microsoft’s FileCAB troubleshooting series on diagnosing Windows Server Backup failures lists 0x807800A1, 0x8078006B, 0x8078008A and the range 0x8078001F to 0x80780025 as errors whose origin is in an underlying layer such as VSS or Shared Protection Point. Event 521’s own message text agrees, because it says the shadow copy operation failed. So the sequence is: convert the number, check the facility, then follow the message text to the next log.

There are three separate places the truth about a failed backup lives, and they do not hold the same thing. Knowing which one answers which question saves a lot of clicking.

# failures: the Application log is where 517 and 521 land
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-Backup'} -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# successes: a DIFFERENT channel, and event 4 is the one that means it worked
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Backup'; Id=4} -MaxEvents 5

# the text logs name the individual files, which the events never do
Get-ChildItem "$env:windir\Logs\WindowsServerBackup" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

The PowerShell equivalents

The WindowsServerBackup module arrives with the same feature and covers the same ground, with one real advantage: it returns objects, so you never parse text. The mapping is close to one for one for the read commands.

Two snippets show why the object route is easier for reporting. The first lists what exists without touching a version string; the second polls a running job instead of blocking on it.

# no text parsing, no UTC arithmetic, no truncation risk
Get-WBBackupSet | Select-Object VersionId, BackupTime, BackupTarget | Format-Table -AutoSize

# poll instead of blocking, which is what wbadmin get status will not do
while ($j = Get-WBJob) {
    '{0}  {1}' -f $j.JobState, $j.CurrentOperation
    Start-Sleep -Seconds 30
}

Hidden gems

• The command called enable is also the command that reads. wbadmin enable backup with no parameters prints the current schedule. Microsoft’s own event log guidance uses it that way: if the output shows a schedule, a scheduled backup is enabled. It is the least discoverable read command on the list.
• The schedule syntax is narrower than the scheduler. -schedule takes comma separated HH:MM times of day, so it cannot express weekly or fortnightly. Microsoft’s FileCAB post on customising the schedule answers that by driving wbadmin from schtasks instead, with the caveat spelled out in their notes: backups scheduled that way do not appear in the Windows Server Backup interface.
• start systemstatebackup takes exactly two parameters. -backupTarget and -quiet. There is no include and no exclude, so a system state backup cannot be scoped at all. If you were looking for the exclusion switch, it does not exist rather than being hard to find.
• Bad cluster checking is on by default during a volume recovery. -skipBadClusterCheck turns it off, and Microsoft recommends against using it when recovering to different hardware. Their note is that until you run chkdsk /b, the bad clusters reported on the recovered system might not be accurate.
• A file level recovery has a three way collision policy. -overwrite accepts Overwrite, CreateCopy or Skip, and CreateCopy is the one to reach for when you are restoring into a live folder and cannot afford to lose whatever is there now.
• Remote share permissions are inherited unless you say otherwise. Without -noInheritAcl, Microsoft states that anyone with access to the share can access the backup. With it, the ACL from the -user credentials is applied to the backup folder instead. On a general purpose file share that switch is the difference between a protected backup and a readable one.
• The archive attribute still matters to it. Clearing the archive bit by hand with attrib -A tells backup software a file has not changed. That is a real way to make files quietly vanish from the next incremental run.

Where this matters

• Taking over a server nobody documented. wbadmin get versions followed by wbadmin enable backup tells you in two commands whether backups exist and whether they are still scheduled.
• Restore drills. The identifier discipline is the thing that turns a drill from an argument into a procedure, because everyone types the same value that get versions printed.
• Triaging an overnight failure before the morning stand up. Convert the code in event 517, check whether the facility is 0x8078, and you know within a minute whether the problem is the backup or something underneath it.
• Recovering a domain controller. System state carries Active Directory and NTDS.DIT on a DC, and -itemtype:App with the value ADIFM is the documented route for an install from media restore.
• Working inside WinRE with no catalog. -backupTarget against a volume GUID is how you find out what is on a backup disk from a recovery prompt, which is exactly when you have least patience for guessing.
• Reclaiming a full backup volume. delete systemstatebackup -keepVersions:3 is a one line answer that will not touch the volume backups sitting alongside them.

Tips and limitations

• Everything needs elevation, on every subcommand, including the read only ones. Administrators for the schedule, Backup Operators or Administrators for the rest.
• User registry hives are not covered. Microsoft states plainly that Windows Server Backup does not back up or recover HKEY_CURRENT_USER as part of a system state backup or recovery.
• Adding a disk as a scheduled target formats it. enable backup -addtarget with a disk erases that disk permanently before first use, and only one shared folder can be a target at a time.
• The reference’s syntax lines are not as reliable as its parameter tables. The enable backup syntax block lists -systemState twice and its parameter descriptions refer to -backupTarget, which is not a parameter of that subcommand at all; -addtarget is.
• start sysrecovery exists only inside the Windows Recovery Environment, so its absence from wbadmin /? on a running server is expected.
• Nothing here is a replacement for a backup product with a retention policy. Microsoft’s own positioning is that Windows Server Backup is a single server solution, and that consolidating protection across servers or applications is a different product’s job.
• Verify that a restore works, not that a backup ran. Event 4 in the operational channel says the job finished; only a test restore says the data is usable.

Official documentation

• wbadmin | Microsoft Learn
• wbadmin get versions | Microsoft Learn
• wbadmin start backup | Microsoft Learn
• wbadmin start recovery | Microsoft Learn
• Windows Server Backup command reference | Microsoft Learn
• System state backup fails: system writer is not found | Microsoft Learn
• WindowsServerBackup module | Microsoft Learn

Related tools

• Windows Event Log Analyzer: paste event 517 or 521 straight out of Event Viewer and get the entry broken down, which is the step before converting the error code.
• Unix Timestamp Converter: shows UTC alongside local time, which is the conversion the version identifier forces you to do by hand.

Related guides

• vssadmin command in Windows: the writer states behind almost every backup failure, and the bracketed number that vssadmin list writers prints instead of a useful word.
• Robocopy backup scripts: the file level alternative when you do not need versioning, and the article that points at Windows Server Backup when you do.
• findstr and find in Windows: explains the /c: literal match that keeps the banner lines out of the loop in example 2.
• Get-WinEvent for event logs: how to filter the Application log and the operational channel for the events this page relies on.
• wevtutil command in Windows: the CMD route to the same two event channels when PowerShell is not available.
• schtasks for scheduled tasks: how to run wbadmin on a weekly or fortnightly schedule that -schedule cannot express.
• diskpart command guide: assigning a letter to a hidden backup volume, and reading volume GUIDs for -backupTarget.
• chkdsk switches and online scan: the /b run that a volume recovery with -skipBadClusterCheck leaves you owing.
• bcdedit and the boot configuration: what you deal with after a bare metal recovery, and where the elevation check in the prerequisites is explained.