Learn Active Directory - Active Directory Backup & Recovery

#Introduction

In episode 16 we saw how replication keeps all DCs consistent — and we also met the tombstone, the marker that keeps deleted objects "alive" for a period before they truly vanish. Now we face a more serious question: what happens when an entire DC fails, when an important object is deleted, or when the directory structure is corrupted? The answer lies in backup and recovery.

Imagine replication as a fire brigade: it prevents fire from spreading. But once the fire is out and the building is destroyed, you need insurance — that's backup. Replication protects against one DC's failure, but it doesn't protect against human error: if an admin deletes the wrong OU, replication will dutifully spread that mistake to every DC. The only savior in cases like this is a data copy made before the mistake happened.

#Why DCs Must Be Backed Up

A DC stores data that can't simply be reconstructed: SYSVOL, the NTDS.dit database holding all objects and permissions, and DNS state. Two main reasons DC backup is mandatory:

1. Human error is the most common cause. Object deletion, wrong mass attribute changes, or "runaway" scripts can't be fixed by replication — because replication actually spreads those errors.
2. Protection from single failure. If all DCs in a domain are lost (disaster, ransomware, corrupted VMs), the domain can't be served — and recovery from scratch takes days.

The governing principle: replication keeps many copies of the same data; backup keeps copies of data at different points in time. The two complement each other, not replace each other.

#System State Backup: The Core of DC Backup

The correct DC backup is a System State backup — because it covers the critical components a regular file backup doesn't: the registry, the AD database (NTDS.dit), SYSVOL, and boot files. Backing up "only document files" on a DC is like insuring the office furniture while the keys and archives go uninsured.

Microsoft's most practical built-in tool is Windows Server Backup (WSB). Install the feature first with Install-WindowsFeature:

Install-WindowsFeature -Name Windows-Server-Backup

Then run scheduled System State backups. For a direct command-line backup:

wbadmin start systemstatebackup -backupTarget:E: -quiet

Routine scheduling (ideally daily, minimum weekly) via WSB, Task Scheduler, or a wbadmin script is the minimum habit that deserves to be called "having a backup".

#ntdsutil: The AD Database Surgery Tool

For deeper needs, there's ntdsutil — a command-line tool that can maintain the AD database: checking integrity, performing offline defragmentation, creating snapshots, and testing restore capability. When a DC is damaged and needs a restore, ntdsutil is one of the main doors in.

Example flow for testing the database snapshot (metadata) while it's inactive:

ntdsutil
snapshot
list all
quit
quit

This is only a small part of ntdsutil's capabilities — the important thing is to know it exists and serves as the "surgery tool" when WSB isn't enough.

#DSRM: Emergency Mode for Restores

Restoring the AD database can't be done while a DC runs normally — the database is in use. That's why Windows provides DSRM (Directory Services Restore Mode), a special boot mode that loads a DC without fully running AD services, so the database can be replaced.

At boot, press the same key as Safe Mode (F8) and select Directory Services Restore Mode. The DC will ask for the DSRM password — the password you set when promoting the DC in episode 5, and which should already be rotated periodically. In DSRM, AD is offline; this is where the database restore happens.

The general non-authoritative restore sequence:

1. Boot the DC into DSRM.
2. Restore System State from the backup using wbadmin:

   Restore System State from the latest backup

   wbadmin get versions -backupTarget:E:
   wbadmin start sysrecovery -version:08/03/2026-04:00 -backupTarget:E: -quiet

3. Restart the DC normally. Once online, the DC copies the latest changes from other DCs via replication.

#Non-Authoritative vs Authoritative Restore

Here's where the most decisive difference lies. When you restore System State, the restored database is an old database — possibly behind the other DCs. How does AD treat the restored data?

• Non-authoritative restore — the restored data is treated as stale (outdated) compared to other DCs, so the DC catches up via replication. This is the right choice when only one DC is damaged: just restore that DC, then let replication bring it in line with the healthy DCs.
• Authoritative restore — the restored data is treated as the source of truth (authoritative) and will overwrite other DCs via replication. This is used when the restored data must win — for example, objects wrongly deleted that have already spread. Without the authoritative treatment, the tombstone (episode 16) would "absorb" the objects you restore.

The way to mark objects as authoritative is via ntdsutil, in restore mode:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "OU=Karyawan,DC=corp,DC=local"
quit
quit

#Active Directory Recycle Bin: The Modern Way to Restore Objects

Restoring from backup is expensive and risky. Since Windows Server 2008 R2, AD offers a far simpler path: the Active Directory Recycle Bin — an analogy to the Recycle Bin on your desktop, but for directory objects.

Its operation is closely tied to the tombstone from episode 16. Deleted objects don't immediately become tombstones — they enter a deleted phase and can be restored in full (all attributes and group memberships), then end up as recycled after a period. As long as the object is still deleted (not yet recycled), it can be recovered without any backup at all.

An important requirement: a forest functional level of Windows Server 2008 R2 or higher, and enabling it cannot be undone:

Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
    -Scope ForestOrConfigurationSet -Target "corp.local"

Once active, restoring objects is done with two simple cmdlets — Get-ADObject to find and Restore-ADObject to restore:

Get-ADObject -Filter {Deleted -eq $true -and Name -like "*Joko*"} `
    -IncludeDeletedObjects -Properties whenChanged, name, lastKnownParent

Restore-ADObject -Identity "e8f9a5c2-..."

#Forest Recovery: The Worst-Case Scenario

When all DCs in a forest are lost or corrupted (major disaster, ransomware wiping everything), replication is useless — there's no other DC to sync with. This is forest recovery: the procedure to rebuild the forest from one DC restored from backup, then promote other DCs one by one.

The main steps are the reverse of normal installation:

1. Restore one DC from a System State backup, making it the forest's "seed".
2. Clean up metadata of dead DCs so they don't disturb the topology.
3. Promote new DCs to replace the lost ones, letting replication rebuild.
4. Recover FSMO roles (episode 3) that may have been lost along the way.
5. Verify — dcdiag, repadmin, and user authentication.

The key to successful forest recovery is two things often forgotten: documented procedures and routine drills. A forest whose recovery has never been tested is like a parachute that's never been opened — you hope it works, but you're not sure.

#Conclusion

In this episode we dissected Active Directory backup and recovery: System State backup with Windows Server Backup and wbadmin, ntdsutil as the database surgery tool, DSRM as the emergency restore mode, the crucial difference between non-authoritative restore (catching up to other DCs) and authoritative restore (overwriting other DCs), the Active Directory Recycle Bin as the modern way to restore deleted objects, and forest recovery for the worst-case scenario.

The takeaway: AD backup is insurance you must pay before a disaster, not after. Replication protects against DC failure; backup protects against human error; and the combination — plus routinely tested procedures — determines how quickly an organization gets back up when the worst happens.

In the next episode 18, we open a new chapter: Active Directory Certificate Services (AD CS) — the PKI foundation enabling certificates, smart cards, and encryption in the enterprise. Keep the momentum going!