Backing up and restoring a Windows Server with Windows Server Backup (wbadmin)

Goal

Install Windows Server Backup, take a full or system-state backup with wbadmin, confirm recovery points exist, and verify that a restore actually works before relying on the backup in an incident.

Prerequisites

Local administrator rights; a target volume or network share separate from the volumes being backed up (backing up a volume to itself is not supported); the Windows-Server-Backup feature installed.

Steps

1. Install the feature non-interactively: Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools.
2. Take a full backup of specific volumes to a dedicated target disk: wbadmin start backup -backupTarget:E: -include:C:,D: -allCritical -quiet. -quiet suppresses the confirmation prompt so the command does not hang in an unattended script; -allCritical includes the volumes the OS needs to be bootable. Without -vssFull the run is a VSS copy backup, which leaves application logs (for example SQL Server or Exchange) untruncated.
3. For a lighter, faster backup that covers the registry, AD DS (on a domain controller), and other system components without the full data volumes, take a system state backup instead: wbadmin start systemstatebackup -backupTarget:E: -quiet.
4. List available recovery points: wbadmin get versions -backupTarget:E:, which reports a version identifier (a timestamp) needed to target a specific restore.
5. Test a restore before you need one for real. A safe routine test is a file restore to a scratch folder: wbadmin start recovery -version:<identifier> -itemType:File -items:D:\Data\sample.txt -recoveryTarget:D:\RestoreTest -quiet. Never run wbadmin start systemstaterecovery -version:<identifier> -backupTarget:E: -machine:<name> as a test on a production server: to the original location it overwrites the running system state and needs a restart, and on a domain controller it must run in Directory Services Restore Mode. Test it on an isolated copy of the server instead (-recoveryTarget only extracts the files to an alternate folder).

Expected result

wbadmin get versions lists the completed backup with a version identifier; a test restore completes and the recovered system or files are usable.

Limits and test basis

wbadmin, wbadmin start backup, wbadmin start systemstatebackup, wbadmin get versions, wbadmin start recovery, and wbadmin start systemstaterecovery are documented Windows commands. Windows Server Backup does not, by itself, provide application-consistent backups of every workload (some server roles need their own VSS writer registered and functioning, and some applications need a dedicated backup agent) and it does not replace off-host or offline copies for ransomware resilience, since a backup target left continuously attached and writable is itself at risk. Retention depends on the target: a backup to a remote shared folder overwrites the previous backup of the same computer there (a failed run can leave no usable backup), while a local volume or dedicated disk keeps several versions as space allows; consult the target sizing before scheduling. No reboot is required for backup or restore of data volumes; a system state recovery to the original location requires a restart afterwards, and a bare-metal recovery runs from the Windows Recovery Environment.