System State, Full Server and Bare-Metal Recovery
A backup job completing successfully does not automatically mean a Windows Server can be recovered.
That distinction becomes important when a server fails.
An administrator may have hundreds of gigabytes of backup data but still face a basic question:
Which recovery method should we use?
Restoring one deleted file is different from recovering a damaged Windows installation.
Recovering Active Directory requires different planning from rebuilding a Hyper-V host.
Replacing a failed system disk may require a complete server recovery rather than copying files back to a new Windows Server installation.
A useful backup strategy starts with recovery scenarios.
What could fail?
What needs to be restored?
How quickly does the server need to return to service?
And what information is required to perform the recovery when the original system is unavailable?
This guide explains Windows Server 2025 backup and recovery planning, including Windows Server Backup, file and volume protection, system state backups, full server backups, bare-metal recovery, and practical recovery testing.
If you are preparing a new deployment, start with our Windows Server 2025 Installation Guide.
For existing Windows Server 2022 systems moving to the new release, review the Windows Server 2022 to 2025 Upgrade Guide before changing the operating system.
Table of Contents
- Start with the Recovery Scenario
- What Is Windows Server Backup?
- Installing Windows Server Backup
- File and Folder Backup
- Volume Backup
- Full Server Backup
- What Is a System State Backup?
- What Is Bare-Metal Recovery?
- System State vs Bare-Metal Recovery
- How to Create a Windows Server 2025 Backup
- How to Configure a Scheduled Backup
- Using wbadmin for Windows Server Backup
- Where Should Windows Server Backups Be Stored?
- Active Directory Backup Planning
- Hyper-V Backup Planning
- Application-Aware Backups
- How to Test a Windows Server Backup
- Common Windows Server Backup Mistakes
- Windows Server Backup Checklist
- Frequently Asked Questions
Start with the Recovery Scenario
Many backup plans begin with storage.
The first question is often:
How much backup space do we need?
Storage capacity matters, but it should not be the first question.
Start with failure scenarios.
For example:
Scenario 1: A User Deletes a File
A user accidentally deletes a business document from a file server.
The operating system is healthy.
The server is online.
Only the file needs to be recovered.
This is a file-level recovery scenario.
Scenario 2: A Windows System File Is Damaged
The server still starts, but Windows has lost or damaged important system components.
Business data may still exist.
This may require system-level recovery rather than restoring a user document.
Scenario 3: The System Disk Fails
The server no longer starts because the operating system volume is unavailable.
A replacement disk is installed.
The server operating system, boot environment, and critical volumes need to be recovered.
This is where bare-metal recovery planning becomes relevant.
Scenario 4: A Domain Controller Fails
The failed server contains Active Directory Domain Services and SYSVOL.
Recovery planning must account for the domain controller role and the state of the remaining Active Directory environment.
Scenario 5: A Hyper-V Host Fails
The host operating system is unavailable.
Virtual machines may be stored on separate surviving storage—or the VM storage may also be lost.
These are two different recovery scenarios.
The backup design should answer each scenario before a failure occurs.
A backup product is not the recovery plan.
The recovery procedure is the plan.
What Is Windows Server Backup?
Windows Server Backup is a Windows Server feature for basic backup and recovery operations.
It can be used to protect Windows Server data and system components according to the selected backup configuration.
Administrators may use Windows Server Backup for tasks such as:
- File recovery
- Folder recovery
- Volume backup
- System state backup
- Full server backup
- Bare-metal recovery preparation
Windows Server also includes the wbadmin command-line utility for backup and recovery operations.
Windows Server Backup can be useful for smaller server environments and specific recovery requirements.
It should not automatically be treated as a complete enterprise data protection platform.
Larger environments may require features such as:
- Centralized backup management
- Multiple retention policies
- Off-site replication
- Cloud backup
- Application-aware protection
- Automated recovery testing
- Reporting and alerting
- Large-scale virtual machine protection
Choose the backup platform according to the recovery requirements.
Do not select a backup method only because it is included with Windows Server.
Installing Windows Server Backup
Windows Server Backup may need to be installed as a Windows Server feature before it is available.
On a Server with Desktop Experience installation, open Server Manager.
Select:
Manage
↓
Add Roles and Features
Continue through the wizard until you reach the Features section.
Select:
Windows Server Backup
Complete the feature installation.
Windows Server Backup can then be opened through the Windows Server management tools.
On Server Core or automated deployments, Windows Server Backup can also be installed using PowerShell.
For example:
Install-WindowsFeature Windows-Server-Backup
After installation, verify that the feature is available before relying on the server’s backup configuration.
Installing the feature does not create a backup automatically.
The backup schedule, destination, and protected data still need to be configured.
File and Folder Backup
File-level backup is designed around recovering data rather than rebuilding the entire server.
Consider a file server containing:
D:\CompanyData
The folder contains:
- Finance documents
- HR files
- Project data
- Shared department folders
If a user deletes one spreadsheet, rebuilding Windows Server would make no sense.
The recovery requirement is:
Restore the missing spreadsheet.
A backup strategy protecting the required file data allows the administrator to recover the relevant file or folder from an available backup version.
File-level recovery is useful for scenarios such as:
- Accidental deletion
- Unwanted file changes
- Damaged files
- Recovery of an earlier file version
Retention becomes important here.
Suppose the file was deleted 45 days ago.
The user notices the problem today.
A backup system retaining only seven days of recovery points cannot restore the 45-day-old file.
The backup job may be healthy.
The retention policy does not match the recovery requirement.
This is why backup planning should include both:
What is protected?
and
How long are recovery points retained?
Volume Backup
A volume backup protects a selected Windows volume.
For example:
- C:
- D:
- E:
This can be useful when server data is organized by volume.
Imagine a file server with:
C:
Windows Server operating system
D:
Business data
E:
Application data
The backup strategy may need different protection for each workload.
The business data volume may require frequent backups and longer retention.
The operating system may be protected through full server or bare-metal recovery planning.
Application data may require a vendor-specific backup method.
Do not assume that selecting every drive in one generic backup job creates the best recovery design.
Understand what each volume contains.
A drive letter is not a workload description.
Full Server Backup
A full server backup protects the volumes required for the server configuration selected in Windows Server Backup.
The purpose is broader than restoring an individual file.
A full server backup is useful when the recovery plan needs to account for the complete Windows Server environment.
This may include:
- Operating system components
- System configuration
- Critical volumes
- Server data included in the backup
The exact recovery procedure depends on the failure.
If Windows Server still starts, an administrator may recover selected data.
If the server cannot start, a system recovery process may be required.
A full server backup should not be confused with simply copying the contents of C: to an external drive.
Windows Server contains:
- Boot configuration
- Protected system files
- Registry data
- Services
- System configuration
A normal file copy does not provide the same recovery capability as a backup designed for server recovery.
What Is a System State Backup?
System state backup protects critical Windows Server system components.
The exact components included depend on the server role.
For a domain member, system state includes components such as:
- Boot files
- Registry
- COM+ class registration database
For a domain controller, system state also includes Active Directory-related components such as:
- Active Directory database
- SYSVOL
Other server roles can add role-specific system state components.
For example, certificate services and failover clustering can introduce additional protected system information.
This is why system state is not simply:
A backup of the Windows folder.
System state is a logical collection of critical operating system and role components.
Its recovery purpose is also specific.
A system state backup can be useful when Windows starts but important system files, registry data, or role-specific system components need to be recovered.
It is not a replacement for business data backup.
If a user deletes a 50 GB file share, system state recovery is not the correct method for restoring those documents.
Protect file data separately.
What Is Bare-Metal Recovery?
Bare-metal recovery is designed for more serious server failure scenarios.
Consider this situation:
A physical server’s system disk fails.
Windows Server does not start.
A replacement disk is installed.
There is no working Windows Server environment on the new disk.
The recovery requirement is not:
Restore one folder.
The requirement is:
Rebuild the server operating system and critical system volumes from backup.
Bare-metal recovery, often abbreviated as BMR, is designed for this type of system recovery.
A BMR backup includes the operating system files and data on critical volumes required for recovery.
By definition, bare-metal recovery protection includes system state.
The recovery process can be used when a server cannot start and the operating system environment needs to be restored.
Microsoft also documents BMR as a supported recovery approach in Active Directory forest recovery planning.
Bare-metal recovery should be part of the discussion for critical physical Windows Server systems.
System State vs Bare-Metal Recovery
System state and bare-metal recovery solve different problems.
| Recovery Type | Typical Purpose |
|---|---|
| File Backup | Restore files or folders |
| Volume Backup | Recover data from a selected volume |
| System State | Recover critical OS and role configuration |
| Bare-Metal Recovery | Recover a failed or non-booting server environment |
| Full Server Backup | Broader server protection and recovery |
Consider a domain controller.
If Windows starts but important system components need recovery, system state may be relevant to the recovery process.
If the complete server has failed and must be rebuilt from a recovery environment, BMR may be required.
Now consider a file server.
If one user deletes a folder, neither system state nor BMR is the first recovery choice.
Restore the folder from the file data backup.
The correct backup type follows the recovery scenario.
This is why one backup method should not be expected to solve every server failure.
How to Create a Windows Server 2025 Backup
After installing Windows Server Backup, open the management console.
In Server Manager, select:
Tools
↓
Windows Server Backup
Select Local Backup.
Windows Server Backup provides options for creating a one-time backup or configuring a schedule.
For a one-time backup, select:
Backup Once
The wizard asks whether you want to use scheduled backup settings or create different options for the current backup.
When creating a separate backup configuration, choose the appropriate backup type.
You may be able to select:
- Full server
- Custom
Full Server
Use the full server option when the backup plan requires protection of the complete server configuration included by the wizard.
Review the estimated backup size before continuing.
Custom
The custom option allows you to select specific items.
Depending on the server and selected components, this may include:
- Volumes
- Files
- System state
- Bare-metal recovery components
Select the items according to the documented recovery requirement.
Do not choose a smaller backup simply to save storage without understanding what will no longer be recoverable.
After selecting the backup configuration, choose the destination and start the backup.
Monitor the job until it completes.
Then review the backup status.
A configured job is not a completed backup.
How to Configure a Scheduled Backup
A production backup strategy should not depend on an administrator remembering to manually start a backup every Friday.
Windows Server Backup supports scheduled backup configuration.
Open Windows Server Backup and select:
Backup Schedule
The wizard allows you to define the protected items and backup timing.
Before choosing a schedule, review the workload.
Ask:
- How frequently does the data change?
- How much data can the business afford to lose?
- How long does the backup take?
- Does the backup affect application performance?
- When is the server least busy?
A daily backup may be sufficient for one server.
Another workload may require more frequent protection through a different backup platform.
The correct schedule is related to the Recovery Point Objective, or RPO.
If the business can tolerate losing up to 24 hours of file changes, a daily recovery point may align with that requirement.
If losing four hours of data is unacceptable, one daily backup is not enough.
Do not choose backup frequency based only on what is convenient for the administrator.
Choose it according to acceptable data loss.
RPO and RTO: Two Numbers Every Backup Plan Needs
Backup planning becomes easier when two recovery targets are documented.
Recovery Point Objective
RPO defines how much data loss is acceptable.
Example:
RPO: 4 hours
The backup and replication design should provide recovery points that limit potential data loss according to that target.
Recovery Time Objective
RTO defines how quickly the service should be restored.
Example:
RTO: 8 hours
The recovery process should be designed to return the required service within that target.
Consider a 10 TB file server.
A complete backup exists.
The backup is stored on slow remote storage.
Restoring all data takes four days.
The backup may be valid.
If the business requires the file server to return within eight hours, the recovery design does not meet the RTO.
Backup success and recovery performance are separate measurements.
Document both.
Using wbadmin for Windows Server Backup
Windows Server includes the wbadmin command-line utility.
It can be used to perform backup and recovery operations from an elevated command prompt.
For example, system state backup operations can be started with wbadmin.
A basic system state backup command follows this structure:
wbadmin start systemstatebackup -backuptarget:E:
This starts a system state backup and uses the specified backup target according to the command configuration.
The wbadmin tool also provides commands for:
- Starting backups
- Viewing backup versions
- Recovering files
- Recovering volumes
- System state operations
- System recovery
Before using wbadmin in production scripts, review the parameters for the exact command.
Test the process.
Do not copy a backup command from an old server and assume it protects the same volumes and workloads on a new deployment.
Automation makes backup operations repeatable.
It can also make an incorrect backup configuration repeatable.
Verify what the command protects.
Where Should Windows Server Backups Be Stored?
Backup destination design matters as much as the backup job.
A common mistake is storing the only backup on the same server being protected.
Consider this layout:
C:
Windows Server
D:
Business data
E:
Backup
All three volumes are located on the same physical server and the same storage system.
A backup job copies D: to E:.
This may help if a user deletes a file from D:.
It does not provide strong protection against:
- Storage controller failure
- Complete server loss
- Theft
- Fire
- Major hardware damage
- Certain security incidents
The backup exists on the same failure domain as the production data.
A stronger backup design separates production and recovery copies.
Depending on the environment, backup destinations may include:
- Dedicated backup storage
- Another physical system
- Network backup infrastructure
- Off-site storage
- Cloud backup services
- Offline or logically isolated recovery copies
The specific platform is less important than understanding failure domains.
Ask:
If the production server and its storage disappear today, does the backup still exist?
If the answer is no, the recovery strategy needs additional protection.
The 3-2-1 Backup Principle
The 3-2-1 principle is a useful starting point for backup design.
The traditional model recommends:
3 copies of data
Production data plus two additional copies
2 different storage types or systems
Avoid depending on one storage platform
1 copy off-site
Protect against site-level failure
Modern environments may extend this approach with immutable or offline recovery copies.
The exact architecture depends on the organization.
A small business and a multi-datacenter enterprise will not deploy identical backup infrastructure.
The principle is useful because it forces the team to think beyond:
The backup job says Successful.
Backup copies should be separated from the systems and failure scenarios they are designed to protect against.
Active Directory Backup Planning
Domain controller backup requires special attention.
A domain controller contains Active Directory data and SYSVOL.
System state backup on a domain controller includes Active Directory-related components.
However, Active Directory recovery should be planned at the directory level, not only at the individual server level.
Ask:
- How many domain controllers exist?
- Are they in one site or multiple sites?
- Is replication healthy?
- Which domain controllers hold FSMO roles?
- Are system state or full server backups available?
- Is the Directory Services Restore Mode password documented securely?
- Does the team understand forest recovery?
Microsoft’s Active Directory forest recovery guidance recommends preparing appropriate backups for recovery scenarios, including BMR protection for full server recovery planning.
Do not assume:
We have three domain controllers, so we do not need backups.
Replication provides availability.
Replication is not a replacement for backup.
If an unwanted directory change replicates between domain controllers, replication can distribute the problem.
Active Directory requires both redundancy and recovery planning.
Hyper-V Backup Planning
A Hyper-V environment introduces two layers.
Hyper-V Host
The physical or parent operating system runs the Hyper-V role and manages the virtualization environment.
Virtual Machines
The guest systems run business workloads.
The backup plan should address both.
Consider a Hyper-V host with five VMs.
If the host operating system fails but VM storage remains healthy, the recovery process may focus on restoring or rebuilding the host and reconnecting the virtual machine infrastructure.
If the VM storage is also lost, host recovery alone does not restore the guest workloads.
The virtual machines need their own protected recovery data.
This is why a Hyper-V host bare-metal backup should not automatically be treated as a complete VM backup strategy.
Document:
- Host configuration recovery
- VM backup
- Application consistency inside VMs
- VM storage protection
- Recovery order
Recovery order can matter.
For example:
- Network infrastructure
- Domain services
- Database services
- Application servers
- User-facing services
Starting every VM simultaneously after a major failure may not be the correct recovery procedure.
For virtualization licensing and multi-host planning, see our Windows Server Hyper-V Licensing Guide.
Application-Aware Backups
A file existing in a backup does not automatically mean an application can recover from it.
Consider a database.
The database service may be actively writing data while a backup is created.
Copying database files without application coordination can create an inconsistent recovery point.
Windows uses Volume Shadow Copy Service, or VSS, to help applications and backup software coordinate consistent snapshots when supported.
Backup applications may use VSS writers associated with server workloads.
Before protecting a business application, check the application’s backup documentation.
Ask:
- Does the application support VSS-aware backup?
- Does it require a database-native backup?
- Are transaction logs protected?
- Is a specific backup agent required?
- What is the documented restore process?
Applications such as databases, messaging platforms, and business systems may require workload-specific protection.
Do not assume that a full server backup replaces every application backup procedure.
The operating system recovery plan and the application data recovery plan should work together.
How to Test a Windows Server Backup
A backup that has never been restored is an untested recovery assumption.
Testing does not always mean intentionally destroying the production server.
The recovery process can be validated in controlled ways.
Test File Recovery
Restore a test file to an alternate location.
Verify:
- The correct backup version is available.
- The file can be recovered.
- The recovered file opens.
- Permissions are understood.
Review Backup Versions
Confirm that the expected recovery points exist.
Do not assume a 30-day retention policy is working because it was configured six months ago.
Test Application Recovery
For critical applications, use an isolated recovery environment where appropriate.
Verify that the application can use the restored data.
Document Bare-Metal Recovery Steps
Even if full BMR testing is not performed frequently, document:
- Required installation or recovery media
- Backup location
- Network configuration
- Storage drivers
- Recovery credentials
- Recovery sequence
Record Recovery Time
Measure how long the test takes.
If the RTO is four hours and the tested recovery takes nine hours, the problem has been identified before a real outage.
That is the purpose of recovery testing.
Backup Monitoring Is Part of the Backup System
Backup jobs fail.
Storage fills up.
Credentials expire.
Network paths become unavailable.
Backup agents stop.
A backup process that nobody monitors can remain broken for weeks.
Define who reviews:
- Backup job status
- Failed jobs
- Warning states
- Backup storage capacity
- Retention
- Last successful recovery point
For critical servers, backup failures should generate an alert.
The alert should reach someone responsible for acting on it.
A mailbox containing 300 unread backup failure messages is not a monitoring system.
Assign ownership.
Common Windows Server Backup Mistakes
Storing the Only Backup on the Same Server
This creates a shared failure domain.
Use separate recovery storage.
Backing Up Data Without Planning the Restore
A backup job is only half of the process.
Document recovery steps.
Using System State as a File Backup
System state protects critical Windows and role components.
It does not replace business file protection.
Assuming Full Server Backup Replaces Application Backup
Business applications may require workload-specific or application-aware protection.
Review vendor documentation.
Never Testing Recovery
Successful job status does not prove that the required service can be restored within the expected time.
Test recovery.
Ignoring Retention
A backup may work perfectly and still be unable to recover a file deleted 60 days ago if only seven days of recovery points are retained.
Treating RAID as Backup
RAID can provide storage redundancy.
It does not provide historical recovery points.
If a file is deleted, encrypted, or corrupted, RAID can preserve the changed or damaged state across the storage array.
Treating Hyper-V Checkpoints as Backups
Checkpoints are useful virtualization tools but should not automatically be treated as a complete backup and disaster recovery strategy.
Use a backup process designed for the workload.
Not Protecting Active Directory
Multiple domain controllers provide redundancy.
They do not eliminate the need for Active Directory recovery planning.
No Off-Site Recovery Copy
A backup stored only inside the production site may be unavailable during a site-level incident.
Review off-site or separated recovery options.
Windows Server 2025 Backup Checklist
For each Windows Server, document:
- Server name
- Server role
- Business owner
- Protected volumes
- Protected applications
- Backup method
- Backup destination
- Backup frequency
- Retention period
- RPO
- RTO
- System state requirement
- Bare-metal recovery requirement
- Application-aware backup requirement
- Off-site copy
- Last successful backup
- Last recovery test
- Recovery documentation location
Then answer five questions:
- Can we restore one deleted file?
- Can we recover the Windows Server operating system?
- Can we recover the business application?
- Can we recover if the physical server or storage is lost?
- How long does each recovery take?
If one of these questions has no answer, the backup design is incomplete.
Frequently Asked Questions About Windows Server 2025 Backup and Recovery
Does Windows Server 2025 include a backup tool?
Windows Server includes Windows Server Backup as an installable feature for basic backup and recovery operations. The wbadmin command-line utility is also available for supported backup and recovery tasks.
What is a system state backup?
System state backup protects critical Windows Server system and role components. The included components depend on the server role and can include boot files, the registry, Active Directory data, and SYSVOL.
What is bare-metal recovery?
Bare-metal recovery is designed to recover the operating system and critical volumes when a server cannot start and requires a complete system recovery.
Does bare-metal recovery include system state?
Yes. Bare-metal recovery protection includes system state as part of the required system recovery data.
Is system state backup enough for a file server?
System state does not replace backup of business file data. File and folder data should be protected according to the required retention and recovery objectives.
Is RAID a backup?
No. RAID provides storage redundancy but does not provide independent historical recovery points for deleted, changed, or corrupted data.
Are Hyper-V checkpoints backups?
Hyper-V checkpoints should not automatically be treated as a complete backup strategy. Use backup protection designed for the virtual machines and their applications.
Should domain controllers be backed up?
Active Directory environments should have a documented recovery strategy. System state and full server or BMR protection may be part of that plan depending on the recovery scenario.
How often should Windows Server be backed up?
Backup frequency should follow the workload’s acceptable data loss, or RPO. A server that can tolerate 24 hours of data loss has different requirements from a system with a one-hour RPO.
How often should backup recovery be tested?
Recovery testing frequency should reflect the importance and rate of change of the server. Critical workloads should have a documented and regularly validated recovery process.
Where should Windows Server backups be stored?
Backup copies should be separated from the production failure domain. Depending on the environment, this may include dedicated backup infrastructure, another system, off-site storage, cloud backup, or isolated recovery copies.
Can Windows Server Backup replace enterprise backup software?
Windows Server Backup can support basic server backup and recovery requirements. Environments needing centralized management, advanced retention, large-scale VM protection, reporting, or automated recovery capabilities may require a broader backup platform.
Final Thoughts
Windows Server backup planning should begin with failure scenarios.
A deleted file does not require the same recovery process as a failed system disk.
A damaged Windows installation is different from a lost Hyper-V storage volume.
A domain controller requires different recovery planning from a standalone application server.
Define what needs to be recovered.
Then choose the backup type.
Use file or volume protection for data recovery requirements.
Use system state when critical Windows Server and role components need protection.
Plan bare-metal recovery for scenarios where the operating system and critical server volumes must be rebuilt.
For applications, verify whether workload-specific or application-aware backup is required.
Store recovery copies outside the production server’s failure domain.
Monitor backup jobs.
Document retention.
And test recovery.
The purpose of a backup is not to create backup files.
The purpose is to return a server or business service to an operational state after something fails.
If you are deploying a new server, follow our Windows Server 2025 Installation Guide.
For Windows Server 2022 systems moving to the new release, review the Windows Server 2022 to 2025 Upgrade Guide.
For Hyper-V environments, continue with the Windows Server Hyper-V Licensing Guide.
You can also return to the Complete Windows Server Licensing Guide for broader Windows Server licensing and deployment planning.