Active Directory & Identity
Active Directory & Identityadvanced18 min read·Updated Sep 1, 2026

Active Directory Backup and Authoritative Restore on Windows Server 2025

Back up and recover Active Directory on Windows Server 2025 with System State, DSRM, non-authoritative recovery, authoritative object restore, Recycle Bin, and tested recovery planning.

Genuine, fully-licensed Windows
Spin up a Windows Server: full admin, RDP-ready
Genuine Windows Server 2019, 2022, or 2025 with full administrator access. We handle the Microsoft licensing, billed monthly with nothing to buy upfront.

In short

An Active Directory backup is not the same thing as taking a VM snapshot. For a domain controller, the recovery plan should include an Active Directory-aware backup such as System State, a documented Directory Services Restore Mode (DSRM) path, and a clear decision for when to use Recycle Bin, a non-authoritative restore, an authoritative restore, or a broader forest recovery procedure.

For most administrators, the important decision is not simply "How do I restore AD?" but what failed, what remains healthy, and which recovery scope is actually required.

Text
What failed? | |-- One deleted user / OU | -> Recycle Bin first, if enabled and eligible | |-- One failed DC, other DCs healthy | -> usually replace/rebuild the failed DC after health checks | |-- Need an older directory object/state to win replication | -> authoritative restore may be appropriate | |-- Restoring a DC from System State while healthy partners exist | -> non-authoritative restore, then replication updates it | `-- Forest-wide corruption / compromise / loss -> formal isolated forest recovery plan

This guide owns Active Directory backup and recovery intent: System State backup, backup verification, DSRM recovery concepts, non-authoritative vs authoritative restore, deleted-object recovery choices, and post-restore validation.

It does not replace the generic Windows VPS Backup Strategy for Small Businesses, Snapshot vs Backup, or Active Directory Replication Topology for 2-DC Setups.

Important: Recovery commands in this guide can change or overwrite directory state. Use them only in a controlled recovery plan. For production incidents, follow Microsoft’s current recovery documentation and validate the exact scenario before making changes.

Why Active Directory needs both replication and backup

A business can have two healthy domain controllers and still need backups.

Replication improves availability, but replication also copies changes. If an administrator deletes an OU, modifies a critical directory object, or an attacker makes destructive changes, those changes can replicate to other domain controllers.

That creates three separate requirements:

  1. Availability — more than one healthy domain controller when the business requires resilience.
  2. Recovery points — trusted backups that predate the failure or unwanted change.
  3. Recovery procedure — a documented way to restore only the required scope without creating a larger outage.

This is why Active Directory design should treat a second DC and a backup as complementary controls rather than substitutes.

Understand the recovery paths before taking action

The safest AD recovery starts by classifying the incident.

IncidentFirst recovery path to evaluateWhy
Accidentally deleted user or OUActive Directory Recycle BinUsually less disruptive than restoring a DC from backup
One DC is lost, another healthy DC remainsReplace/rebuild the failed DCHealthy replication partners may already hold the correct directory state
Restore a DC and let current directory data replicate back to itNon-authoritative restoreRestored DC is brought up to date by healthy partners
Restore an older object and make that restored version replicate outwardAuthoritative restoreThe selected restored object or subtree is made authoritative
Entire forest is compromised or unusableForest recoveryRequires isolated, domain-by-domain recovery planning

Do not choose an authoritative restore simply because the name sounds stronger. It is more invasive because you are deliberately making restored directory data take precedence over newer replicated copies.

Active Directory Recycle Bin should usually be checked first for deleted objects

Windows Server 2025 supports Active Directory Recycle Bin. When enabled, it can preserve deleted AD objects and their attributes so eligible objects can be restored without rolling a domain controller back to an older System State.

Check whether Recycle Bin is enabled:

Powershell
Get-ADOptionalFeature -Filter 'Name -like "Recycle Bin Feature"' | Select-Object Name, EnabledScopes

If EnabledScopes contains the forest configuration, Recycle Bin is enabled.

Microsoft documents two important limitations:

  • Active Directory Recycle Bin is not enabled by default;
  • only objects deleted after Recycle Bin was enabled can be recovered through it.

A discovery command can be used to inspect deleted test objects:

Powershell
Get-ADObject -Filter 'Name -Like "*RestoreLab*"' -IncludeDeletedObjects

After confirming the exact identity of the intended object, a restore can be performed with Restore-ADObject.

For production, do not pipe a broad search directly into Restore-ADObject until you have reviewed the returned objects. Narrow the filter and confirm identifiers such as DistinguishedName or ObjectGUID first.

System State is the core Active Directory-aware backup

Microsoft’s current Windows Server forest-recovery guidance documents System State backup for domain controllers.

On a domain controller, System State contains the operating-system state required for Active Directory recovery, including AD DS data and related components.

That makes System State different from a generic file copy.

A complete production strategy can also include full-server or bare-metal recovery, platform-level backups, application backups, and copies outside the live server. These layers address different failure modes.

Protection layerPrimary job
AD System StateActive Directory-aware DC recovery
Full server / BMR backupRestore the whole server/OS when required
VM/platform backupInfrastructure-level recovery point
SnapshotShort-lived pre-change rollback
AD Recycle BinRecover eligible deleted AD objects
Second DCAuthentication/DNS availability and replication partner

A snapshot alone is not an Active Directory recovery strategy.

Step 1 — Record the domain-controller environment

Before creating the backup, record exactly what is being protected.

Run PowerShell as Administrator:

Powershell
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber hostname Get-Service NTDS,DNS,Netlogon,ADWS | Select-Object Name,Status Get-ADDomain | Select-Object DNSRoot,NetBIOSName,PDCEmulator,RIDMaster,InfrastructureMaster Get-ADForest | Select-Object ForestMode,SchemaMaster,DomainNamingMaster

If you have more than one DC, record them as well:

Powershell
Get-ADDomainController -Filter * | Select-Object HostName,Site,IsGlobalCatalog,IPv4Address

This matters during recovery because you need to know whether the failed server was the only DC, a DNS server, a Global Catalog, or an FSMO role holder.

Step 2 — Confirm Windows Server Backup is available

Windows Server Backup is not installed by default on every Windows Server installation.

Check the feature:

Powershell
Get-WindowsFeature Windows-Server-Backup

If the feature is not installed and Windows Server Backup is part of your recovery design:

Powershell
Install-WindowsFeature Windows-Server-Backup

Verify again:

Powershell
Get-WindowsFeature Windows-Server-Backup

Step 3 — Choose a backup target that survives the failure you care about

The only recovery copy should not disappear with the domain controller.

A production backup design should consider:

  • failure of the OS volume;
  • accidental VM deletion;
  • administrator compromise;
  • ransomware;
  • failure of one host or storage path;
  • loss of an entire DC;
  • the need to recover from an older trusted point.

A second partition on the same virtual disk is useful for limited testing, but it is not an independent production backup target because failure of the underlying VM or disk can remove both the source and the backup.

Where possible, use a separate backup destination such as another protected storage system or supported network share that remains available if the DC is lost.

The generic Raff backup strategy page owns retention, off-server copies, RPO/RTO, and layered backup design. This article focuses specifically on AD-aware backup and recovery decisions.

Step 4 — Create a System State backup with wbadmin

Microsoft documents wbadmin start systemstatebackup for Windows Server.

Example using a deliberately prepared backup volume:

Cmd
wbadmin start systemstatebackup -backupTarget:E: -quiet

Replace E: with the destination defined by your recovery design.

Windows Server also supports a remote shared folder as a backup target. Example syntax:

Cmd
wbadmin start systemstatebackup -backupTarget:\\backup-server\ADBackup -quiet

Use a real protected share and appropriate credentials. Do not expose SMB publicly just to make a backup target reachable.

Without -quiet, wbadmin prompts for confirmation.

You can monitor an active job with:

Cmd
wbadmin get status

Do not treat a command starting successfully as proof that the backup completed successfully. Confirm the final result and then verify the recovery point.

Step 5 — List the available backup versions

After the backup completes, use:

Cmd
wbadmin get versions

Microsoft documents that this returns information such as:

  • backup time;
  • backup location;
  • version identifier;
  • recovery types available from the backup.

If the backup is on a specific local target:

Cmd
wbadmin get versions -backupTarget:E:

Record the version identifier. wbadmin uses that value when you inspect or restore a specific recovery point.

Inspect the items in a selected backup with:

Cmd
wbadmin get items -version:<MM/DD/YYYY-HH:MM>

Use the actual version returned by your server. Do not copy an example timestamp into a production recovery command.

Step 6 — Decide whether you actually need to restore this DC

A failed domain controller in a healthy multi-DC domain is not automatically a restore job.

If another writable DC is healthy and replication was healthy before the failure, rebuilding a clean replacement server and promoting it as a new DC may be simpler and safer than restoring an old DC image.

Before restoring one failed DC, inspect the surviving environment:

Cmd
repadmin /replsummary
Cmd
dcdiag /e /c

And in PowerShell:

Powershell
Get-ADDomainController -Filter * | Select-Object HostName,Site,IsGlobalCatalog

The decision changes if:

  • this was the only DC;
  • the surviving directory contains bad replicated changes;
  • the forest was compromised;
  • a specific historical directory object/state must be recovered;
  • the backup is the only trusted copy.

Non-authoritative restore: let healthy partners update the restored DC

A normal domain-controller restore from System State is non-authoritative unless you deliberately mark restored data authoritative.

Conceptually:

Text
Trusted System State backup | v Restore DC | v Start AD DS normally | v Healthy replication partners send newer directory changes | v Restored DC becomes current

Use this when the objective is to return a failed DC to service while healthy replication partners contain the correct newer state.

Microsoft documents wbadmin start systemstaterecovery for System State recovery. A typical command shape is:

Cmd
wbadmin start systemstaterecovery -version:<MM/DD/YYYY-HH:MM> -backupTarget:E:

The exact command depends on where the backup is stored and the supported recovery scenario. Do not run System State recovery on a production DC as an experiment.

Microsoft also distinguishes restoring System State to the same system from recovering onto a new or reinstalled operating-system instance. For a different server instance, follow Microsoft’s supported full-server or bare-metal recovery guidance rather than assuming a System State copy can simply be applied to a fresh installation.

Authoritative restore: make selected restored data win replication

An authoritative restore is different.

The purpose is to restore directory data from backup and deliberately mark selected objects or a subtree so that the restored version is treated as newer and can replicate outward to other domain controllers.

This may be relevant when:

  • an OU was deleted and Recycle Bin cannot provide the required recovery;
  • multiple objects need to return to a previous state;
  • a trusted backup contains the version that must supersede later replicated changes.

It should be used at the smallest scope that solves the problem.

Microsoft’s Active Directory recovery guidance documents ntdsutil authoritative-restore operations for selected directory objects and subtrees.

Example command shape for a specific object:

Cmd
ntdsutil "authoritative restore" "restore object <object DN>" q q

For a subtree:

Cmd
ntdsutil "authoritative restore" "restore subtree <container DN>" q q

Do not authoritatively restore the domain root or a large production subtree merely to recover one object. A broader authoritative scope can revert unrelated attributes, memberships, and other changes that occurred after the backup was taken.

Recycle Bin vs authoritative restore

Use this decision rule:

ConditionBetter first option
Recycle Bin enabled before deletion and object is recoverableRecycle Bin
Object was deleted before Recycle Bin was enabledBackup-based recovery may be required
Need to recover an object plus historical state not preserved elsewhereEvaluate authoritative restore
Entire domain/forest state is suspectUse formal forest/domain recovery planning

Recycle Bin is generally less disruptive because it avoids restoring an entire domain controller just to recover a deleted object.

Authoritative AD objects are not the same as authoritative SYSVOL

This distinction is important.

Microsoft documents authoritative synchronization of DFSR-replicated SYSVOL as a separate procedure from authoritative restoration of directory objects.

Do not use the terms interchangeably:

Text
Authoritative AD object restore -> selected directory objects or subtree Authoritative SYSVOL recovery -> SYSVOL / DFSR recovery procedure

A production forest recovery may require both directory and SYSVOL decisions, but they solve different problems.

DSRM is a recovery mode, not a normal administration mode

Directory Services Restore Mode allows a domain controller to start without normal AD DS operation so offline directory recovery tasks can be performed.

The DSRM password is configured when the server is promoted to a domain controller. Treat it as a high-value recovery credential.

For Windows Server environments using Windows LAPS, Microsoft also supports managing DSRM credentials through Windows LAPS when configured appropriately.

Before an incident, verify that:

  • the organization knows how to retrieve the DSRM password;
  • the credential is stored securely;
  • the procedure is documented outside the failed server;
  • recovery staff understand the difference between the normal domain Administrator account and DSRM credentials.

Never expose a real DSRM password in screenshots, tickets, scripts, or public documentation.

Validate Active Directory after any restore

A restore is not finished when the recovery command returns success.

Check core services:

Powershell
Get-Service NTDS,DNS,Netlogon,ADWS | Select-Object Name,Status

Check domain-controller health:

Cmd
dcdiag

If multiple DCs exist, check replication:

Cmd
repadmin /replsummary

Then validate the specific object or subtree that was recovered.

For example:

Powershell
Get-ADOrganizationalUnit -Filter 'Name -eq "RaffRestoreLab"' | Select-Object Name,DistinguishedName

For a test user:

Powershell
Get-ADUser -Filter 'Name -like "*RestoreLab*"' | Select-Object Name,SamAccountName,Enabled,DistinguishedName

Also validate the parts of the environment that depend on Active Directory:

  • AD-integrated DNS records;
  • SYSVOL and NETLOGON shares;
  • authentication from an intended client or test system;
  • Group Policy if the recovered scope includes GPO-related data;
  • FSMO role ownership;
  • event logs for AD DS, DNS, DFS Replication, and System errors.

Do not restore an old DC snapshot blindly

Virtualized domain controllers have protections designed for supported virtualization scenarios, but a snapshot is still not a replacement for an Active Directory-aware backup and recovery plan.

The practical rule is:

Text
Snapshot before a risky change != Long-term AD recovery strategy

Use Snapshot vs Backup on a Windows VPS for the infrastructure-level distinction.

For Active Directory, keep trusted System State or supported full-server recovery points and validate the recovery process before an incident.

One-DC lab vs two-DC production recovery planning

One-DC environment

A one-DC environment is simple but fragile:

Text
DC01 -> AD DS -> DNS -> Global Catalog -> System State backup

If that DC is lost, there is no healthy replication partner to rebuild from. The quality and accessibility of the backup become much more important.

Two-DC production baseline

A typical small production domain might be:

Text
Private / trusted network DC01 <------ AD replication ------> DC02 | | AD DS AD DS DNS DNS GC GC | | System State backups System State backups

Two DCs improve availability. They do not remove the need for backups because destructive directory changes can replicate.

For topology, DNS client order, sites, and replication checks, use Active Directory Replication Topology for 2-DC Setups.

Forest recovery is a separate severity level

If the entire forest is compromised, corrupted, or unusable, do not treat the incident as a routine authoritative restore.

Microsoft’s forest-recovery guidance describes restoring at least one domain controller in every domain from trusted backup and performing recovery in a controlled sequence.

Forest-wide recovery requires decisions about:

  • which backup is known-good;
  • which DC to recover first in each domain;
  • isolation from compromised or unhealthy replication partners;
  • DNS and SYSVOL recovery;
  • FSMO roles;
  • privileged-identity recovery after compromise;
  • reconnecting recovered domains safely;
  • application and service dependencies.

That deserves a dedicated recovery runbook and drill. This article stops at the point where the incident becomes a forest recovery project.

How to choose a trusted backup

The newest backup is not automatically the safest backup.

If destructive or malicious changes happened at an unknown time, the latest recovery point may already contain the unwanted state.

Track backup metadata alongside AD health:

RecordWhy it matters
Backup versionIdentifies the exact recovery point
DC hostnameShows which DC was protected
Windows buildHelps verify the restore scenario
Domain/forestPrevents restoring the wrong environment
Backup targetShows where recovery media is stored
Last known-good AD healthHelps identify a trusted point
dcdiag resultRecords directory health around backup time
repadmin /replsummaryRecords replication health in multi-DC environments
Change windowHelps correlate bad changes with backup time

For business-critical AD, routine health logging makes disaster recovery easier because you can identify when the environment was last known to be healthy.

Backup and restore testing cadence

A practical small-business or MSP baseline is:

TaskSuggested cadence
Verify backup job completedEvery backup cycle
Review available System State versionsWeekly or according to backup schedule
Review dcdiag / replication healthRegularly and after AD changes
Confirm DSRM recovery credentialsQuarterly / controlled policy review
Restore a test object with Recycle BinPeriodically in a lab
Recovery drill from backupPeriodically based on business impact
Review forest-recovery runbookAfter topology or security changes

The exact frequency should follow the organization’s RPO, RTO, change rate, and risk.

Common Active Directory backup mistakes

Treating replication as backup

Replication copies deletions and bad changes. Two DCs are not two historical recovery points.

Using only a VM snapshot

A snapshot is useful for short-term rollback, but it should not be the only recovery layer for a domain controller.

Keeping the only backup on the same VM or disk

That may validate a command in a lab, but it does not protect against complete VM, disk, or account loss.

Backing up but never recording the version

A backup without a documented recovery point makes incident response slower. Use wbadmin get versions and record the version identifier.

Restoring a DC when rebuilding it would be simpler

If healthy replication partners exist and hold the correct directory state, replacing the failed DC can be cleaner than reviving an old one.

Using authoritative restore too broadly

Restore the smallest directory scope that solves the problem. A broad subtree can revert unrelated directory changes.

Confusing SYSVOL authoritative recovery with AD object authoritative restore

They are separate procedures with different targets.

Losing the DSRM password

DSRM is part of the recovery path. Protect and verify credential retrieval before the outage.

Testing recovery for the first time during a production incident

A recovery plan is stronger when it has been rehearsed in an isolated or disposable environment before it is needed.

Where Raff fits

Raff’s role is the Windows Server infrastructure layer.

A production Active Directory deployment can use dedicated Raff Windows VMs for domain controllers while the administrator controls AD DS, DNS, security policy, backup scheduling, and recovery procedures inside Windows Server.

A production-minded architecture can look like this:

Text
Raff Windows VM - DC01 + Raff Windows VM - DC02 + AD-aware System State backups + independent recovery copies + periodic recovery testing

The value is not simply adding more compute. It is separating identity workloads intentionally, maintaining more than one domain controller where availability requires it, and keeping recovery copies outside the failure boundary of the active DC.

A second dedicated Windows VM can improve DC availability. A separate Windows VM or protected storage target can also support isolated backup or recovery workflows when the design requires it.

Raff provides the VM infrastructure. Active Directory architecture, backup policy, recovery testing, and directory administration remain administrator responsibilities unless a separate managed service explicitly covers them.

Active Directory recovery readiness checklist

CheckReady when
At least one trusted AD-aware backup existsSystem State or another supported recovery backup is current
Backup version is documentedwbadmin get versions identifies the recovery point
Backup survives the failure you are protecting againstOne VM or disk loss does not remove every recovery copy
DSRM password retrieval is knownRecovery staff can retrieve it securely
Recycle Bin status is documentedAdministrators know whether deleted-object recovery is available
DC roles are documentedDNS, GC, FSMO, sites, and replication partners are known
Restore decision tree existsRebuild vs non-authoritative vs authoritative vs forest recovery is clear
Recovery has been rehearsedThe team has validated the procedure in a safe environment
Post-restore checks are documentedAD DS, DNS, SYSVOL, objects, and replication are validated
Recovery notes live outside the DCDocumentation survives server failure

If those items are missing, the environment may have backups but not yet a complete Active Directory recovery plan.

Frequently asked questions

What should I back up on an Active Directory domain controller?

Use an Active Directory-aware recovery method. Microsoft documents System State backup for domain controllers, and full-server or bare-metal recovery can also be part of the disaster-recovery design. Platform snapshots and VM backups can be useful additional layers but should not be the only AD recovery plan.

Is a second domain controller a backup?

No. A second DC improves availability and provides another replica, but deletions and bad directory changes can replicate to it. Keep historical recovery points as well.

What is a non-authoritative Active Directory restore?

It restores a DC from backup and then allows healthy replication partners to bring that DC up to date with newer directory changes.

What is an authoritative Active Directory restore?

It restores directory data from backup and marks selected objects or a subtree so the restored version takes precedence and replicates outward. Use the smallest necessary scope.

Should I use authoritative restore for a deleted user?

First check Active Directory Recycle Bin. If Recycle Bin was enabled before deletion and the object is recoverable, it is usually the less disruptive path. Backup-based authoritative recovery is for cases where Recycle Bin cannot solve the requirement or where historical directory state must intentionally become authoritative.

Can I restore a System State backup onto a fresh Windows Server installation?

Do not assume so. Microsoft distinguishes same-system System State recovery from recovery onto a new or reinstalled operating-system instance. Follow the supported full-server or bare-metal recovery guidance for the actual scenario.

Does wbadmin get versions prove the backup is usable?

It proves that Windows can enumerate the recovery point and its metadata. It does not replace a real recovery drill.

Can I put a System State backup on a network share?

Yes. Windows Server Backup supports remote shared folders as backup targets. Use an authenticated, protected share and avoid exposing SMB publicly.

Do snapshots replace System State backup for virtual domain controllers?

No. Snapshots can help with short-term rollback, but a domain controller still needs an AD-aware backup and recovery plan.

What’s next

Sources

Was this article helpful?

Published September 1, 2026 · Updated September 1, 2026

Back to hub
Ready when you are

Your Windows Server, live in ~55 seconds

Genuine, fully-licensed Windows with full admin and RDP. We handle the Microsoft licensing, billed monthly with nothing upfront. On NVMe SSD, backed by a 14-day money-back guarantee.

Related articles