Active Directory Backup and Forest Recovery: What Actually Works When Your DCs Go Down
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Active Directory is the authentication and authorization backbone for most enterprise environments -- if AD fails, nearly everything else fails with it. Despite this, most organizations have never tested whether their AD backup can actually recover a domain. AD restore is more complex than regular server restore because of multi-master replication, USN rollback risk, SYSVOL synchronization requirements, and the authoritative vs non-authoritative restore decision. This guide covers the minimum viable backup procedure and the recovery decision tree for common AD failure scenarios.
What to Back Up and How Often
What constitutes a complete AD backup:
-
System State: Includes NTDS.dit (the AD database), the SYSVOL folder tree, the system registry, and the boot files. System State backup is the minimum for DC recovery.
-
Full server backup: System State plus the OS volume. Required if you need to restore the entire DC from scratch (OS + AD).
Backup frequency:
- System State: Daily, at minimum every 48 hours (the default inter-site replication latency)
- Full server backup: Weekly
- Retention: 60+ days (tombstone lifetime is 60 days by default; any backup older than this cannot restore deleted objects)
Back up using Windows Server Backup (built-in):
# Install Windows Server Backup feature if not present
Install-WindowsFeature Windows-Server-Backup
# Perform System State backup to a local path or network share
wbadmin start systemstatebackup -backupTarget:\\backupserver\ADBackups\$env:COMPUTERNAME -quiet
# Verify the backup completed
wbadmin get status
# List available backups for this server
wbadmin get versions -backupTarget:\\backupserver\ADBackups\$env:COMPUTERNAME
Schedule daily System State backup via Windows Server Backup UI:
- Open Windows Server Backup on each DC
- Backup Schedule > Custom > Add Items > System State
- Schedule: daily, at a low-traffic time
- Destination: a network share or dedicated backup volume
Critical: Protect AD backups from ransomware. Ransomware actors specifically target backup infrastructure. AD backups should go to:
- An immutable backup target (Veeam immutable backups, Azure Backup with soft delete)
- An air-gapped or offline backup location
- A separate backup server not domain-joined (so a domain compromise does not give ransomware access to backups)
Authoritative vs Non-Authoritative Restore
The most important decision in AD recovery is whether you need an authoritative or non-authoritative restore.
Non-authoritative restore (most common): Restores a DC from backup and lets it synchronize with other DCs that have newer AD changes. The restored DC is treated as an outdated peer -- any changes made to AD after the backup date are replicated from other DCs to the restored DC. Use this when:
- A single DC fails and other DCs are healthy
- You are rebuilding a DC after hardware failure
- The backup represents an older (but not authoritative) state
# Perform non-authoritative restore (steps):
# 1. Boot DC into DSRM (F8 on startup, Directory Services Restore Mode)
# 2. Restore system state from backup:
wbadmin start systemstaterecovery -version:<backup-version-from-wbadmin-get-versions> -quiet
# 3. Reboot -- the DC synchronizes with other DCs and catches up to current state
Authoritative restore (specific use case -- object recovery): Restores a DC from backup and marks specific AD objects as authoritative -- the restored version of those objects will overwrite the current version on all other DCs. Use this when:
- AD objects were accidentally deleted (user accounts, OUs, group memberships)
- You need to recover specific objects to a pre-deletion state
# Authoritative restore steps:
# 1. Boot to DSRM
# 2. Restore system state (non-authoritative restore first)
# 3. Before rebooting, run ntdsutil to mark objects as authoritative:
ntdsutil
authoritative restore
restore subtree "CN=John Smith,CN=Users,DC=domain,DC=com"
quit
quit
# 4. Reboot -- the restored, authoritatively marked objects replicate to all DCs
Enable AD Recycle Bin to simplify object recovery:
# Enable the AD Recycle Bin (one-way, cannot be disabled after enabling)
Enable-ADOptionalFeature 'Recycle Bin Feature' `
-Scope ForestOrConfigurationSet `
-Target 'domain.com'
# Recover a deleted user from the Recycle Bin (no authoritative restore needed)
Get-ADObject -Filter {displayName -eq 'John Smith'} -IncludeDeletedObjects |
Restore-ADObject
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Forest Recovery Procedure
A forest recovery is required when all DCs in the domain are compromised or unavailable. This is the worst-case AD failure scenario (ransomware encrypting all DCs, for example).
Forest recovery order:
-
Identify the PDC Emulator DC for each domain: This is the first DC to restore in each domain.
-
Restore the PDC Emulator from the most recent known-clean backup:
- Boot from Windows installation media
- Restore the system state (non-authoritative, then seize FSMO roles)
- Do NOT connect to any network that has other DCs until the forest structure is rebuilt
-
After initial restore, clean metadata:
# Remove references to DCs that have not yet been restored
# (to prevent replication errors)
ntdsutil "metadata cleanup" "remove selected server" <failed-DC-DN>
# Or use Active Directory Users and Computers > Domain Controllers OU
# Right-click a missing DC > Delete
- Raise RID pool (prevents duplicate SIDs from restored DCs):
# In ntdsutil:
seize rid master
# Raise RID pool allocation
-
Rebuild remaining DCs as new promotions (do not restore them from backup -- restore the PDC Emulator and then promote new DCs that replicate from it).
-
Restore SYSVOL and verify GPO replication:
# Check SYSVOL DFSR replication health after restore
Get-DfsrBacklog -GroupName 'Domain System Volume' -FolderName 'SYSVOL Share'
For ransomware recovery: The forest recovery timeline depends on backup recency and whether the backup infrastructure itself was compromised. Organizations with immutable cloud backups (Azure Backup, Veeam with immutable repository) typically recover in hours. Organizations with no clean backup or compromised backup servers may need to rebuild the domain from scratch -- creating new domain, recreating user accounts, re-joining all endpoints.
The bottom line
AD backup minimum viable posture: daily system state backup to an immutable or air-gapped target, 60+ days retention, at least one annual tested restore to a lab environment. Enable the AD Recycle Bin to simplify accidental deletion recovery without needing authoritative restores. For ransomware preparedness, ensure AD backups are in a location that a domain-compromised account cannot reach -- either immutable cloud storage or an offline target not accessible from domain credentials.
Frequently asked questions
Can I use VM snapshots instead of Windows Server Backup for AD?
Not safely. Hypervisor snapshots of DCs can cause USN rollback when reverted -- the DC comes back with replication update sequence numbers that are behind what partner DCs have already processed. This causes the restored DC to re-replicate objects that other DCs believe it already has, creating phantom objects, replication conflicts, and in severe cases, requiring the affected DC to be demoted and re-promoted. If you must use VM-level backup, use a backup product with AD-aware VSS support (Veeam, Azure Backup, Commvault with AD plugin) that specifically handles USN rollback prevention. Never revert a DC snapshot taken while the domain was running without verifying USN rollback has not occurred.
How do I test an AD backup restore without affecting production?
Build an isolated lab environment: a set of VMs on an isolated virtual network with no connectivity to production. Restore the DC backup to a VM in this isolated network, let it complete recovery, and verify: that domain logins work in the lab, that Group Policy applies correctly, that SYSVOL contains the expected GPO templates, and that LDAP queries return the expected objects. The lab should be truly isolated -- if it can reach your production network, the restored DC will attempt to replicate with production DCs, potentially causing issues. Document the restore time (how long it took from starting the restore to a functional domain) -- this is your RTO estimate for a real incident.
How do I recover specific deleted AD objects without a full restore?
If the AD Recycle Bin is enabled (requires domain functional level Windows Server 2008 R2 or later), deleted objects are retained for 60 days by default and can be recovered with a single PowerShell command: Get-ADObject -Filter {displayName -eq 'ObjectName'} -IncludeDeletedObjects | Restore-ADObject. If the Recycle Bin is not enabled, deleted objects go directly to tombstone state and you need an authoritative restore from backup to recover them -- the tombstoned object retains most attributes but loses some (group memberships, for example) and recovery requires booting to DSRM. Enable the Recycle Bin before you need it; enabling it after deletion is too late for already-deleted objects.
What is the recovery time objective (RTO) for an AD forest recovery?
For a single DC failure in a domain with multiple DCs: 30 minutes to 4 hours (rebuild the DC from backup or promote a new DC). For a full domain failure with a tested backup and documented procedure: 4 to 12 hours. For a full forest recovery with multiple domains and no documented procedure: 1 to 7 days. For a forest recovery with no clean backup or a compromised backup: weeks, potentially requiring full domain rebuild, re-enrollment of all endpoints, and password resets for all accounts. The gap between a tested procedure (hours) and untested (days or weeks) is why annual AD recovery exercises are a meaningful risk reduction investment.
What should be included in the AD forest recovery runbook that most organizations overlook?
Most runbooks cover the technical restore steps but miss these critical dependencies: (1) DNS recovery -- AD DNS is stored in the AD database; if AD is restored but DNS records are stale, domain-joined machines cannot locate DCs; the runbook should include DNS verification steps. (2) Certificate Authority recovery -- enterprise CAs store issued certificate data in AD; if the CA database is not in sync with the restored AD state, certificate revocation and issuance break. (3) Network access without Kerberos -- during forest recovery, Kerberos is unavailable; document how IT staff will authenticate to systems using local accounts and LAPS passwords. (4) External trust dependencies -- applications that federate with AD via ADFS or Entra Connect need those services restarted and verified after the AD restore. Test the full dependency chain during your annual recovery exercise, not just the DC restore itself.
How do I protect AD backups from ransomware that targets backup infrastructure?
Ransomware groups specifically target backup infrastructure because encrypted backups make organizations more likely to pay. AD backup protection requires: offline or immutable backups (tape, offline drives, or cloud object storage with immutability enabled such as S3 Object Lock or Azure Blob immutable storage) that the ransomware cannot reach via network or compromised credentials, backup credentials stored separately from production AD (if the backup service account is in AD and AD is compromised, the attacker has the backup credentials), backup encryption using keys stored in a separate key management system (not protected by AD credentials), and backup infrastructure on a separate network segment with no inbound access from production servers. Test the backup independently by performing a bare-metal restore to an isolated network -- the test should include recovering to a state before the simulated compromise, not just verifying that the backup file exists.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.