> ## Content Index > Fetch the complete content index at: https://blog.sudowl.com/llms.txt > Use this file to discover other available public pages before exploring further. # wbadmin — Free Bare-Metal Backup on Windows Server - URL: https://blog.sudowl.com/wbadmin-windows-server-bare-metal-backup/ - Published: 2026-06-04T10:00:00.000Z - Updated: 2026-10-11T08:26:51.000Z - Description: Free bare-metal backup on Windows Server with wbadmin and Windows Server Backup — one-off image, scheduled policy, and the full WinRE recovery drill. - Author: Lukas - Tags: Windows Server 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](https://blog.sudowl.com/restic-backup-s3-minio-encrypted/). **TL;DR — install and take a bare-metal image of C: to E::** ```powershell Install-WindowsFeature Windows-Server-Backup ``` ```cmd wbadmin start backup -backupTarget:E: -include:C: -allCritical -vssFull -quiet ``` Details below. ## Install the feature It's not on by default. PowerShell: ```powershell Install-WindowsFeature Windows-Server-Backup -IncludeAllSubFeature ``` That gives you both `wbadmin.exe` and the `WindowsServerBackup` (`WB*`) PowerShell module. No reboot. Confirm: ```powershell Get-WindowsFeature Windows-Server-Backup Get-Command -Module WindowsServerBackup ``` If you're still on a fresh box, do the [initial setup checklist](https://blog.sudowl.com/windows-server-initial-setup-checklist/) first — disk layout matters here. ## One-off bare-metal image ```cmd 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: ```cmd wbadmin enable backup -addtarget:{disk-id} -schedule:02:00 -include:C: -allCritical -vssFull -quiet ``` Get the target disk identifier first: ```cmd 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: ```powershell $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: ```powershell 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: ```cmd 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: ```cmd 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: ```cmd 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](https://blog.sudowl.com/bitlocker-windows-server-os-volume/), 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: ```cmd wbadmin get versions vssadmin list writers ``` ```powershell 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 - [Hosting a Website on IIS — Windows Server Without the Bloat](https://blog.diengdoh.com/iis-host-website-windows-server/?ref=blog.sudowl.com) - [Hyper-V on Windows Server — Your First VM Without the GUI](https://blog.diengdoh.com/hyper-v-create-first-vm-windows-server/?ref=blog.sudowl.com) - [DHCP on Windows Server — Scopes, Reservations, and the Gotchas](https://blog.diengdoh.com/windows-server-dhcp-setup/?ref=blog.sudowl.com)