How to Back Up and Restore Active Directory on Windows Server 2025

How to Back Up and Restore Active Directory on Windows Server 2025

Active Directory (AD) is the backbone of authentication, authorization, and policy management in most enterprise environments. Losing your domain controllers without a reliable backup means losing user accounts, group policies, computer objects, and trust relationships — a catastrophic event that can take days to recover from manually. Windows Server 2025 includes robust built-in tools for protecting AD data, including Windows Server Backup, wbadmin, and the Active Directory Recycle Bin. This guide walks through a complete strategy for backing up and restoring AD — covering system state backups, authoritative and non-authoritative restores, and GPO-specific backup procedures.

Prerequisites

• At least two domain controllers (DCs) in the domain — Microsoft requires a minimum of two DCs for any production AD environment
• Windows Server Backup feature installed on each DC you intend to back up
• A backup target: local disk, network share, or attached USB drive with sufficient space
• Domain Admin or Backup Operators group membership
• Windows Server 2025 forest and domain functional level (recommended) to enable all Recycle Bin features
• Basic familiarity with PowerShell and the RSAT AD tools

Step 1: Install Windows Server Backup

The Windows Server Backup feature is not installed by default. Install it with PowerShell on every domain controller you plan to protect:

# Install Windows Server Backup feature
Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools

# Confirm installation
Get-WindowsFeature Windows-Server-Backup

If you manage multiple domain controllers, you can install the feature remotely using PowerShell remoting:

# Install on remote DC
$DCs = @('DC01', 'DC02', 'DC03')
Invoke-Command -ComputerName $DCs -ScriptBlock {
    Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools
}

Step 2: Perform a System State Backup with wbadmin

A system state backup on a domain controller captures the AD database (NTDS.dit), the SYSVOL share, the registry, the COM+ class registration database, and the boot files. This is the minimum required to restore Active Directory. Run the following from an elevated PowerShell or Command Prompt session:

# Back up system state to a local volume (volume must NOT be C:)
wbadmin start systemstatebackup -backupTarget:E: -quiet

# Back up system state to a network share
wbadmin start systemstatebackup -backupTarget:\FILESERVER01ADBackups -quiet

# Check available system state backups
wbadmin get versions -backupTarget:E:

For automation, schedule this as a daily task. Use the Windows Server Backup snap-in (wbadmin Schedule) or Task Scheduler to run the above command nightly:

# Schedule a daily system state backup at 02:00
$Action = New-ScheduledTaskAction -Execute 'wbadmin.exe' `
    -Argument 'start systemstatebackup -backupTarget:E: -quiet'

$Trigger = New-ScheduledTaskTrigger -Daily -At '02:00AM'

$Principal = New-ScheduledTaskPrincipal -UserId 'SYSTEM' -RunLevel Highest

Register-ScheduledTask -TaskName 'AD-SystemStateBackup' `
    -Action $Action `
    -Trigger $Trigger `
    -Principal $Principal `
    -Description 'Nightly Active Directory system state backup'

Step 3: Perform a Non-Authoritative Restore

A non-authoritative restore is used when a domain controller has suffered hardware failure or corruption and needs to be rebuilt from backup. After restoration, the DC replicates updated AD data from other DCs in the domain. This is the most common restore scenario.

Boot the server into Directory Services Restore Mode (DSRM). Press F8 during startup and select Directory Services Restore Mode, or set it persistently with:

# Boot into DSRM on next restart (run before rebooting)
bcdedit /set safeboot dsrepair

# After restore is complete, remove the safeboot flag
bcdedit /deletevalue safeboot

Once in DSRM, open Command Prompt as Administrator and restore the system state:

# List available system state backup versions
wbadmin get versions -backupTarget:E:

# Restore using a specific backup version (use the version identifier from above)
wbadmin start systemstaterecovery -version:05/17/2026-02:00 -backupTarget:E: -quiet

# The system will restart automatically after recovery

After reboot, the DC will replicate from its replication partners and catch up to the current AD state.

Step 4: Perform an Authoritative Restore with ntdsutil

An authoritative restore is required when AD objects were accidentally deleted and you need to restore them so they replicate back out to all other DCs — overriding the fact that those DCs have already replicated the deletion. Without marking the restore as authoritative, the deletion will simply replicate back from the other DCs.

Follow the non-authoritative restore steps first (Step 3), but do not reboot after wbadmin finishes. Instead, run ntdsutil to mark objects as authoritative:

# Open ntdsutil (run in DSRM, before final reboot)
ntdsutil

# At the ntdsutil prompt:
activate instance ntds

# Enter the authoritative restore context:
authoritative restore

# Restore a specific OU (subtree):
restore subtree "OU=Finance,DC=contoso,DC=com"

# Restore a single object:
restore object "CN=John Smith,OU=Finance,DC=contoso,DC=com"

# To restore the entire domain (use with extreme caution):
restore database

# Exit ntdsutil:
quit
quit

After the authoritative restore completes, ntdsutil will update the version numbers on the restored objects so they are treated as more current than the copies on other DCs. Reboot the server normally after this step.

Step 5: Enable and Use the Active Directory Recycle Bin

The AD Recycle Bin preserves deleted objects in a recoverable state for the duration of the tombstone lifetime (180 days by default in Windows Server 2025). Unlike an authoritative restore, recovering objects from the Recycle Bin does not require DSRM or downtime, and all object attributes are preserved intact.

# Enable AD Recycle Bin (requires Windows Server 2008 R2+ forest functional level)
# Run once on the PDC Emulator
Enable-ADOptionalFeature 'Recycle Bin Feature' `
    -Scope ForestOrConfigurationSet `
    -Target 'contoso.com'

# Confirm the feature is enabled
Get-ADOptionalFeature 'Recycle Bin Feature' | Select-Object Name, EnabledScopes

Once enabled, recovering deleted objects is straightforward:

# Find deleted objects matching a name
Get-ADObject -Filter {displayName -eq "John Smith"} -IncludeDeletedObjects

# Restore a single deleted user by distinguished name
Restore-ADObject -Identity "CN=John SmithADEL:a1b2c3d4-...,CN=Deleted Objects,DC=contoso,DC=com"

# Restore all deleted objects from a specific OU
Get-ADObject -Filter {IsDeleted -eq $true -and LastKnownParent -eq "OU=Finance,DC=contoso,DC=com"} `
    -IncludeDeletedObjects | Restore-ADObject

# Verify the object is restored
Get-ADUser -Identity "jsmith" -Properties *

Step 6: Back Up Group Policy Objects

GPOs are stored partially in the SYSVOL (file system) and partially in AD (the GPC — Group Policy Container). A system state backup captures both, but for granular, GPO-specific backups you should use the GroupPolicy PowerShell module:

# Import the GroupPolicy module
Import-Module GroupPolicy

# Create a backup directory
$BackupPath = "E:GPO-Backups$(Get-Date -Format 'yyyy-MM-dd')"
New-Item -ItemType Directory -Path $BackupPath -Force

# Back up all GPOs in the domain
Backup-GPO -All -Path $BackupPath -Domain contoso.com

# Back up a single GPO by name
Backup-GPO -Name "Default Domain Policy" -Path $BackupPath

# List backed-up GPOs
Get-ChildItem -Path $BackupPath -Directory | ForEach-Object {
    $Report = Get-GPOBackup -Path $BackupPath -Id $_.Name
    [PSCustomObject]@{
        DisplayName = $Report.DisplayName
        BackupId    = $Report.Id
        Timestamp   = $Report.Timestamp
    }
}

# Restore a GPO from backup
Restore-GPO -Name "Default Domain Policy" -Path $BackupPath

Step 7: Verify and Test Your Backups

A backup that has never been tested is a backup you cannot rely on. Periodically verify your backups in an isolated environment:

# List all available system state backup versions and verify integrity
wbadmin get versions -backupTarget:E:

# Check backup job status and event log entries
Get-EventLog -LogName "Microsoft-Windows-Backup" -Newest 20 |
    Where-Object {$_.EntryType -eq 'Error' -or $_.EntryType -eq 'Warning'}

# Review AD replication health after any restore
repadmin /replsummary
repadmin /showrepl
dcdiag /test:replications /v

Conclusion

Protecting Active Directory on Windows Server 2025 requires a layered approach: regular automated system state backups with wbadmin, a well-practiced restore procedure covering both authoritative and non-authoritative scenarios, the Active Directory Recycle Bin for rapid object recovery, and dedicated GPO backups to protect policy configurations. The most important step you can take beyond implementing these procedures is to test them regularly — restore objects in a lab environment, verify GPO restores produce the expected policies, and ensure your team knows the DSRM password on every domain controller. A disaster is the wrong time to discover a gap in your recovery plan.