About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Windows Server has two recovery types that look similar and behave differently. A bare-metal recovery rebuilds disks and the operating system from a recovery environment, and Microsoft supports it on different hardware. A system state recovery runs inside a working Windows installation, and Microsoft does not support it across a different make, model or hardware configuration.
Choosing the wrong recovery type can invalidate a plan for replacement hardware.
The commands below were not run in a lab. They come from Microsoft documentation, and server names, drive letters and dates are examples.
Recommendations and interpretations are editorial unless attributed; source research is not lab validation.
Why it matters
A file backup does not make a server bootable. To boot, a server needs its partition layout, boot configuration, registry, driver files and any role data held outside ordinary folders, all from a single consistent moment.
Hardware failure also rarely leaves you with an identical replacement. The replacement may have a different RAID controller or network adapter, or it may be a virtual machine. Those differences decide which recovery path is open to you.
This article covers Windows Server Backup and the Volume Shadow Copy Service (VSS) mechanics beneath it. Diagnosing a failing VSS writer, and Active Directory USN rollback, are separate subjects we have published on elsewhere.
How it works
What VSS does during the backup
VSS coordinates three parties: a requester (the backup program), writers (applications that make their data consistent) and providers (which create the shadow copy). Writers finish open transactions and flush caches, then VSS freezes application writes.
Two time limits apply. The application freeze may not exceed 60 seconds, and the shadow copy commit may not exceed 10 seconds, during which file system writes stay frozen. If either limit is passed, the shadow copy can be aborted.
Bare-metal capability comes from one particular writer. The Automated System Recovery (ASR) writer stores the disk configuration, reports the Boot Configuration Data store, and must be included in any backup required for bare-metal recovery. The System Writer lists operating system and driver binaries and is required for system state. You can confirm both are present and stable before a backup:
vssadmin list writers
Critical volumes
A volume is critical if it contains system state information; the boot, system and Windows Recovery Environment (WinRE) volumes are the standard examples. Microsoft states that all critical volumes must be restored or the restore fails.
By that definition, a role that places system state data on a data volume makes that volume critical too. A bare-metal set can therefore be larger than "just C:". Check it on your own servers.
On UEFI computers, the EFI System Partition is hidden and cannot be part of a shadow copy, so backup software must copy its contents separately.
What each backup type contains
Windows Server Backup isn't installed by default, so add the feature before you plan around these commands.
-allCritical includes all critical volumes and is the option for bare-metal recovery. It needs a backup target, and that target cannot be one of the volumes in the backup.
Microsoft's documented command for a bare-metal backup is:
wbadmin start backup -allCritical -backupTarget:E:
That command stops at critical volumes. Microsoft's Data Protection Manager page says a bare-metal backup covers operating system files and all data "except user data not located on critical volumes". On a server with a separate data volume, it gives you a bootable server with no data. -allCritical can be used with -include, so name the data volumes as well (the letters are examples):
wbadmin start backup -allCritical -include:D:,F: -backupTarget:E:
A system state backup is narrower:
wbadmin start systemstatebackup -backupTarget:E:
System state includes boot files, the registry with COM settings, SYSVOL, Active Directory and NTDS.DIT on domain controllers, the certificate store when that service is installed, the IIS metadirectory on web servers, and cluster information on cluster members. It does not include user registry hives (HKEY_CURRENT_USER).
The same page puts the relationship simply: a bare-metal backup includes a system state backup by definition.
Two details catch people out.
The default is a copy backup. -vssCopy leaves file history alone and is the default, while -vssFull updates history and may truncate logs of previous backups. Microsoft's own caution is not to use -vssFull if another product backs up the apps on those volumes. The reverse also holds: a copy backup cannot be used for incremental or differential backups or restores.
A network share keeps only one backup per path. Backing up the same computer to the same remote folder overwrites the earlier backup, and if that run fails you can end up with no usable backup. Microsoft recommends subfolders, which need extra space.
What ASR does to disks at restore
Warning: at restore, disks that were not excluded during backup are re-created and reformatted by default, unless the layout is intact or changed only by additions. For a basic disk, intact means the signature, GPT or MBR style, logical sector size and volume start offset are unchanged, and the volume has not shrunk. A GPT disk must also keep its partition identifier, and a dynamic disk also needs its whole disk pack's volume structure intact.
Four further behaviours follow, all in the same Microsoft page.
Drive letters are not preserved during restore, so restoring software has to use volume GUID paths. Letters you see in the recovery environment are not the ones the server had.
Disk numbers cannot be mapped from backup to restore, because partitions may be created or removed.
The disk holding the backup must be excluded, or it can be overwritten. The graphical wizard excludes it automatically. Do not rely on that at a command prompt.
ASR does not re-create the layout of a cluster's shared disks; restore those online after the operating system is back. Cluster information in system state does not rebuild them.
What to choose and why
The first two columns follow Microsoft's statements, except the physical-to-VM row, which is our own suggestion. The last column is our recommendation.
| Situation | Path | Our recommendation |
|---|---|---|
| Windows boots, and a role or configuration is damaged | System state recovery from the running OS | Use it only on the same hardware |
| Server will not boot, same hardware | Bare-metal recovery from WinRE | Restore critical volumes first, then data |
| Different hardware | Bare-metal recovery is supported; system state is not | Never substitute system state to save time |
| Newer system state on top of a bare-metal move to different hardware | Not supported | Take a fresh backup of the rebuilt server instead |
| BIOS source to UEFI target, or the reverse | Not supported: "You cannot mix the two in a BMR scenario" | Match the firmware mode on the target before you start |
| Domain controller on new hardware, during a forest recovery | Full server recovery is necessary | Follow the forest recovery guide; a single failed controller in a healthy domain is a different case |
| Physical server moving to a VM | Bare-metal recovery, with a storage driver for the virtual controller | Compare it against your hypervisor's conversion tooling |
Current pages carry the main point. The forest guide says a bare-metal backup can be restored to different hardware, and Azure Backup says recovering to different hardware using system state isn't recommended by Microsoft.
The firmware rule and the explicit "not supported" statements come from a page titled How to restore a Windows 7 installation. It was updated in February 2026, and its Applies to line reads "Supported versions of Windows Server". On cross-hardware system state it adds that Microsoft provides only "commercially reasonable efforts", and that even machines that look identical may have different drivers, hardware, or firmware.
A safe order of steps for different hardware
Plan a recovery to replacement hardware
No destructive restore or boot-repair sequence is supplied here because it has not been validated on replacement hardware. The useful output is a plan that names the source, target, backup set, permitted disk changes and acceptance tests.
Microsoft's current forest recovery guidance requires the replacement to have the same number of drives, each the same size or larger. Older Windows Server guidance compares the replacement against the original whole disk, not merely its used space or volume size. Record both disk and partition sizes; do not assume a mostly empty large source disk will restore onto a smaller target.
Build a recovery inventory before an outage. Include firmware mode, logical sector size, storage-controller model, all critical volumes, data volumes, encryption keys and the installed Windows version and architecture. Keep the target's signed storage and network driver packages on media available without the failed server. Recovery-media architecture must match the machine being restored.
Identify the backup and the destination
A backup file's existence does not prove it supports bare-metal recovery. Use the catalogue's version identifier and advertised recovery types, then connect those to the original server and the expected capture time. The documented read-only queries are:
wbadmin get disks
wbadmin get versions -backupTarget:E: -machine:SRV01
The drive letter and machine name are examples. Letters in recovery media can differ from the running server; identify the backup location by its actual volume and contents before interpreting the output. Keep a copy of the disk list and the selected backup identifier with the recovery record.
Map every target disk by its stable identifier, size and intended role. The backup medium, unrelated data disks and storage used by other systems must be explicitly accounted for. A successful command aimed at the wrong disk is still a destructive failure. Have another qualified person review the mapping before any operation that recreates partitions or formats volumes.
Establish the recovery-media path
Microsoft's full-server recovery guidance uses System Image Recovery and includes driver installation and disk-exclusion choices. A missing disk can mean that the recovery environment lacks the controller driver; it does not prove the backup is damaged. The driver available to recovery media is also distinct from the driver required by the restored Windows installation.
A network-hosted backup adds adapter, addressing, name-resolution and authentication dependencies. The older forest-guide route mentions a Hyper-V legacy network adapter, which exists on generation 1 VMs. That does not establish the equivalent path for generation 2. For a UEFI target, validate compatible media and networking in advance rather than changing VM generation to fit an old example.
Measure the actual transfer path. A readable backup on a remote share may take much longer to retrieve than the recovery window permits. Record credentials and key access that remain available when the original directory and server are down, and keep those secrets outside ordinary recovery logs.
Define what the restore is allowed to overwrite
ASR can recreate and reformat disks. The plan must specify the critical-volume restore, any included noncritical volumes, the exclusions and the expected post-restore layout. Disk numbers and drive letters are not reliable substitutes for an explicit destination map.
Command-line disk-exclusion syntax should be confirmed against the installed recovery tool and validated in the rehearsal. The previous illustrative colon form was not independently established, so this article does not publish it as a runnable example. Prefer the supported interface whose choices and exclusions can be recorded and checked by the recovery team.
Storage Spaces and cluster shared disks require separate consideration. Microsoft's older Storage Spaces guidance describes critical-volume recovery first and rebuilding pools inside the operating system before restoring data. Its ASR documentation also distinguishes cluster shared storage from the operating-system layout. Confirm the procedure for the actual Windows release and storage product; a bootable server does not establish that those datasets returned.
Do not add a filesystem repair, disk conversion or boot-file rewrite merely because the first boot fails. Compare firmware, disk attachments, driver availability and the selected boot configuration first. Any subsequent repair must target an identified cause and preserve a route back to the pre-repair disk copy.
Accept the recovered service
The first gate is a repeatable operating-system boot with the intended volumes and storage paths. Inspect system logs and device state, confirm network identity, and verify that encryption protection has been restored as planned. Older Microsoft guidance says BitLocker protection needs explicit attention after system recovery; validate the exact behaviour for the chosen release.
The second gate is role and application recovery. Confirm data volumes, shares, permissions, service accounts, scheduled jobs, certificates and application transactions. A critical-volume restore can complete while ordinary data remains absent, so compare the result against the original inventory rather than the wizard's success message alone.
A domain controller recovered in a forest-recovery scenario also requires the corresponding directory and SYSVOL procedure. A single failed controller in a healthy domain is a different recovery decision. Do not layer an unsupported cross-hardware system-state restore onto a successful bare-metal recovery as an improvised way to get newer data.
Finally, test the backup path on the recovered server and record the time spent retrieving data, restoring disks, booting and validating applications. Keep the old system isolated until the authoritative copy and any target-side writes are accounted for. Recovery to different hardware is proven by that representative rehearsal, not by the general support statement alone.
Risks and limits
- Storage Spaces. On Windows Server 2012 and 2012 R2, the system volume cannot sit on a storage space, and neither Windows Server Backup nor ASR can recreate pools or spaces in WinRE. Microsoft recommends a critical-volume recovery first, rebuilding the pool from your recorded configuration inside Windows, and then recovering data. We found no newer page that changes this; check your release.
- Firmware and disk style. Source and target must both be UEFI or both be BIOS, and the ASR conditions above treat disk style as part of the layout. A UEFI-only replacement therefore cannot take a BIOS and MBR backup by this route. On Hyper-V that means matching the VM generation to the source.
- Bad cluster data. If the bad cluster check was skipped, reported bad clusters might not be accurate until
chkdsk /bruns. - Non-critical volumes. The recovery can succeed with data volumes unrecovered, such as volumes on virtual hard disks or iSCSI disks. Read the final prompt; do not assume everything came back.
- Backup product differences. Backup software that uses the ASR writer directly can request driver injection into the restored boot volume. Its options and limits are the vendor's, and are not covered here.
- Page age. Several statements come from pages for older releases, including the Windows 7 page named above, and the
wbadminreference was last updated in September 2025. They are marked where they matter. - Licensing and activation after a hardware change are outside this article.
Testing is the only real proof. Restore a representative server to the different hardware you would actually use, and time it. A recovery that has never crossed a hardware boundary is an assumption.
Sources
Opened 10 November 2026.
- Volume Shadow Copy Service
- In-box VSS writers
- Using VSS Automated System Recovery for disaster recovery
- wbadmin start backup
- wbadmin start systemstatebackup
- wbadmin start sysrecovery
- wbadmin get versions
- wbadmin get disks
- vssadmin
- AD forest recovery: backing up a full server
- AD forest recovery: performing a full server recovery
- How to restore a Windows 7 installation (Applies to: Supported versions of Windows Server)
- Recover the operating system or full server (Windows Server 2008 R2)
- Windows Server Backup and Storage Pools (2012 and 2012 R2)
- Troubleshoot System State Backup, Azure Backup
- Back up system state and bare metal, Data Protection Manager
- Windows Recovery Environment technical reference
- Generation 1 or 2 virtual machines in Hyper-V
- diskpart list volume
- diskpart assign
- Drvload command-line options
- DISM driver servicing command-line options
- Add and remove drivers to an offline Windows image
- BCDBoot command-line options
This article was originally published on .