How to Back Up Windows Server

Windows Server Backup can create scheduled or one-off backups of a Windows server and restore selected data after a failure. A useful setup needs more than a successful backup job: choose a destination that survives the failures you are planning for, retain the versions you need, and test recovery.

This guide covers the Windows Server Backup feature on Windows Server 2025, 2022, 2019, and 2016. Available options depend on the installed version, server roles, and backup destination.

Before you begin

Decide what you need to recover and how much recent work you can afford to lose. A full-server backup includes the server's volumes and recovery components; a custom backup lets you select supported items. Applications with their own consistency or recovery requirements may also need application-specific procedures.

Choose a destination before scheduling the first job:

A network folder is not necessarily offsite. Check its physical location, credentials, and exposure to the same administrator accounts or ransomware as the source server.

When the same computer backs up repeatedly to the same remote shared folder, Windows Server Backup can overwrite the previous backup. A failed replacement can leave no usable version there. Plan separate destinations or an independently managed retention system if you need older recovery points.

Install the backup feature

Windows Server Backup is an optional feature. Check whether it is installed before adding it.

1. Open Server Manager, then choose Manage → Add Roles and Features.
2. Select Role-based or feature-based installation and choose the intended server.
3. Continue to Features, select Windows Server Backup, and review the installation summary.
4. Click Install and wait for the result. If a restart is required, schedule it for an appropriate maintenance window.

After installation, open Windows Server Backup from Server Manager's Tools menu.

Configure scheduled backups

Select Local Backup, then Backup Schedule. Choose Full server or Custom, review the included items, and set the times when the backup should run.

Choose a frequency that meets your acceptable data-loss window. Off-peak scheduling can reduce contention, but a once-daily backup may be insufficient for a busy database or application.

Review the destination options carefully:

• Dedicated disk: Windows Server Backup prepares the selected disk for backup use. Formatting erases existing data, so verify the disk identity and preserve anything needed before accepting the wizard's warning.
• Existing volume: Backups consume space and I/O capacity that other workloads may need. Measure performance and leave capacity for both the backup and the application.
• Network folder: Use a complete UNC path, such as \\backupserver\backups, and an account with the required access. Review the overwrite risk before relying on this as your only copy.

Confirm the scope, schedule, destination, and credentials before clicking Finish. Watch the first scheduled run and check that you can locate the resulting backup from the recovery interface.

Run a manual backup

A manual backup is useful before a major configuration change or software installation. In Windows Server Backup, select Backup Once. Reuse the scheduled settings when appropriate, or choose Different options to select another scope or destination.

Review the selected items and destination before starting. If the target is a network folder already used for backups, consider whether this run will replace a recovery point you still need.

Wait for completion, inspect any warnings, and confirm that the backup is available for recovery. A completed job alone does not establish that an application can be restored successfully.

Restore files and server data

For a routine restore, open Recover in Windows Server Backup and select the server or location containing the backup. Choose an available backup date, then the recovery type supported by that backup.

Files and folders can be restored individually when the backup supports that recovery type, including supported volume backups. You do not always need to restore an entire volume first. Volume and application recovery have different requirements; system-state recovery covers Windows configuration and role-dependent components, not just ordinary configuration files.

For an initial file-restore test:

1. Select a small set of files whose contents you can verify.
2. Restore to a separate directory so the test does not overwrite working data.
3. Review the handling of existing files and permissions before starting.
4. Open the recovered files and compare their contents and access permissions with your expectations.

Full-system or bare-metal recovery uses the appropriate Windows recovery environment and a suitable backup. Check boot media, drivers, destination disks, encryption keys, and console access in advance. Test application recovery in isolation from production, especially for domain controllers and other services with external dependencies.

Keep backups usable

Monitor results and failures

Review the backup history and the Microsoft-Windows-Backup logs in Event Viewer. Collect alerts for failed jobs, unavailable destinations, and missing scheduled runs. Investigate the full event message rather than relying only on an event number.

Keep an independent copy

Use the 3-2-1 principle as a starting point: three copies, two storage types, and one offsite copy. Also check whether a compromised server account can delete every copy. Offline or appropriately protected immutable copies can help separate backup recovery from that risk.

Plan encryption and key recovery

BitLocker can protect supported Windows volumes at rest. Configure it for the actual source and destination arrangement, and store recovery keys somewhere accessible if the server is lost. Encrypting a source volume does not by itself prove that a separate backup destination is protected.

Test recovery on a schedule

Run the first restore test soon after setup, then repeat it at an interval appropriate to the workload and after material changes. Quarterly testing may be a starting point, but critical services may need more frequent checks. Record recovered data, application behavior, elapsed time, and any missing access or dependencies.

Document the recovery procedure

Keep server names, backup schedules, retention rules, destination paths, recovery access, and restore instructions available independently of the protected server. Another administrator should be able to follow the procedure during an outage.

Windows Server backup limitations

Capacity and retention

Check the supported volume sizes, filesystem, destination type, and free-space requirements for your Windows Server version. A virtual-disk format's maximum size is not a guarantee that every backup layout of that size is supported.

Local backup storage may remove older versions as space is needed. Verify the recovery points actually retained; capacity management is not a promise to keep a fixed number of days.

Network targets

Repeated backups to the same remote folder can replace earlier backups. If you need multiple versions, use a planned destination rotation or backup product with suitable retention. Moving or rotating backup folders also needs a tested recovery procedure and enough storage.

Tape and mixed operating systems

Windows Server Backup does not provide native tape-backup support. Use a suitable backup product for tape or for centrally protecting mixed Windows and Linux systems.

Application recovery

Confirm which application writers and recovery types your backup supports. Databases, directory services, and other stateful workloads may need extra steps to produce a consistent backup and restore it correctly.

Troubleshoot common failures

A network backup fails

Check the configured backup account, share permissions, filesystem permissions, name resolution, and connectivity. Successfully opening the share under your own interactive account does not prove that the scheduled backup account can use it. Use the job's configured credentials and error details to diagnose access; do not grant broad permissions as a shortcut.

A backup takes too long

Compare source-disk activity, destination throughput, network transfer, and the amount of changed data. Exclude disposable caches only after confirming they are unnecessary for recovery. Incremental behavior depends on the backup mode and destination, so measure successive runs rather than assuming every later backup will be faster.

Storage runs out

Inspect retained recovery points and application growth. Increase capacity, revise retention, or adjust the protected scope without removing data needed for recovery. Check the consequence of deleting any backup before doing so, and retain an independent usable copy.

A destination disappears

Test access to the actual share or disk using the backup account. A successful ping does not verify SMB access, credentials, or write permission. Check disk availability, network policy, and job timing. The PowerShell cmdlets for Windows Server Backup can help inspect policies, jobs, and recovery options.

Add cloud backup where it fits

Azure Backup offers separate protection and retention options for supported workloads. Review the required agent or service, supported data, recovery process, ongoing charges, and access controls before adding it to a local backup plan.

Azure Arc can bring supported servers into Azure's management environment. Arc registration by itself does not create a backup or establish a recovery policy.

Put the recovery plan to work

Configure the backup, observe a scheduled run, and restore a representative sample to an isolated location. Compare the result with the downtime and data loss your service can tolerate. Expand the plan until it covers the files, application state, credentials, and infrastructure needed to bring that service back.