# Windows Server Backup 2025: system state, bare metal and a restore you tested

> Install Windows Server Backup, choose a dedicated target, run system-state and bare-metal backups, and prove a restore in a lab before you need it.

**Tested on**

- Build: 26100.33650
- Edition: Standard / Datacenter
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-28

## The short answer

A snapshot is not a backup. Windows Server Backup can do:

- **System state** — AD DS, registry, SYSVOL, boot files; good for a DC/role recovery.
- **Bare metal** — the whole server, restored to dissimilar hardware with the OS media.
- **Files/folders** — selective data.

Use a **dedicated backup target** (a separate disk/volume or network share), keep a copy off the host, and **test a restore** before you trust it.

## Install and target

```powershell
Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools
```

Then `wbadmin` or Server Manager → Tools → Windows Server Backup.

Target rules:

- Do not back up to the volume you are protecting (C: → C: is not a backup).
- A dedicated disk is simpler than a network share; a share is better for off-host copies.
- The target is erased/formatted by Windows Server Backup in many configurations — check before selecting a disk with data.
- BitLocker/encryption on the target protects a stolen drive; store the key separately.

## System state (DC)

```powershell
wbadmin start systemstatebackup -backupTarget:E: -quiet
wbadmin get versions
```

For a domain controller, system state includes AD DS and SYSVOL. A restore of a DC is not the same as restoring a member server:

- prefer restoring a **single DC** while others are offline/isolated;
- do not restore an old DC into a live domain and expect automatic reconciliation;
- authoritative restore is a deliberate operation, not a first try.

## Bare metal / full server

```powershell
wbadmin start backup -backupTarget:E: -include:C: -allCritical -quiet
```

`-allCritical` includes the system/boot/recovery volumes needed for boot. Test the restore in a VM with the same OS media; a backup you have never restored is a hypothesis.

## Verify

```powershell
wbadmin get versions
wbadmin get items -version:MM/DD/YYYY-HH:MM
Get-WBSummary
```

Check:

- the job completed with no errors;
- the target has free space for the next run;
- Event Viewer has no VSS/backup failures;
- a test restore boots/logs in;
- AD/SYSVOL are healthy after a DC restore.

> **Caution: Restoring a DC can reintroduce old data**
>
> A system-state restore can bring back deleted objects and stale passwords. Isolate the DC, understand the USN rollback/authoritative restore implications, and test in a lab first.

## A lab plan

1. Snapshot the VM before the backup test.
2. Create a file and a test AD user.
3. Run system state + file backup.
4. Delete the file/user.
5. Restore to a **clone**, not the original.
6. Verify the file, user and SYSVOL.
7. Document the exact version/time used.

## What not to do

- Do not use a VM snapshot as the only backup.
- Do not back up to the same physical disk.
- Do not restore a DC into production without a recovery plan.
- Do not assume “backup completed” means “restore works”.

## Sources

- [Microsoft Learn — Windows Server Backup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/windows-server-backup-command-reference)
- [Microsoft Learn — wbadmin](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin)
- [Microsoft Learn — AD DS backup concepts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-forest-recovery-guide)

---

Source: https://windows.homes/en/server/roles/backup/