Backups and forest recovery planning

Check the directory’s backup evidence

repadmin /showbackup *

The output reports backup information for directory partitions. If a date looks wrong, check the backup product, selected DCs, protected naming contexts and whether the application-aware operation succeeded. The timestamp won’t tell you whether you can reach the media, retrieve its encryption key or restore it. Microsoft’s backup-age guidance explains the partition-level check.

Build a coverage matrix by naming context, not just by server. Include every domain, schema/configuration and DNS/custom application partitions, the writable replicas that host them, the selected backup source, media/catalog and last restore test. Backing up two DCs in a domain does not establish protection of a custom partition hosted only elsewhere. A GC’s partial copy of another domain is also not that domain’s writable recovery backup.

For an initial local view of the naming contexts reported by a chosen endpoint:

Get-ADRootDSE -Server 'dc1.contoso.com' |
    Select-Object -ExpandProperty namingContexts

Compare the list with the replica topology and backup selection to check that every required full writable copy is covered. Keep the matrix somewhere you can reach without the directory or the backup server’s normal domain-dependent administration path.

Directory Service event 2089 is a backup-latency warning for the named partition. Its threshold is related to directory retention unless configured otherwise; it is not a business recovery-point objective. An organization requiring a few hours of data loss cannot use absence of that event as its backup SLA. Conversely, an old timestamp needs product/API and replica investigation before concluding that no usable media exists.

On a server using Windows Server Backup, list its available versions:

wbadmin get versions

The backup target may need to be supplied when it is not local or registered. Keep the backup product’s own catalog and successful restore test beside the directory evidence.

To inspect a selected Windows Server Backup version, copy the exact identifier from the catalog. This is an illustrative read-only catalog query; replace the version, machine and target:

wbadmin get items -version:11/10/2026-09:00 -backupTarget:E: -machine:DC1

Confirm the expected system state and volumes are present, not merely that a backup entry exists. The Wbadmin item reference defines how the version and target select that backup.

Match the recovery to the failure

The recovery direction matters. A nonauthoritative restored replica accepts newer directory data from partners. An authoritative restore deliberately makes selected restored data win replication. SYSVOL authority is a separate decision from directory object authority. See recovery scope and dependencies, object recovery and SYSVOL health.

File copies and VM snapshots are different tools

A copied ntds.dit is not a complete supported DC backup. Protect the operating system and required volumes using a directory-aware process, and understand whether the chosen recovery needs system state or full server/bare-metal data. Include SYSVOL, DNS dependencies and application partitions in the recovery design.

VM-GenerationID provides rollback safeguards for compatible virtual DCs; it does not create a backup policy or recover changes that never replicated elsewhere. Virtualization notes explain that boundary.

Select media for the recovery target

A system-state restore is not a supported way to transplant a DC into a fresh Windows installation, even on the same hardware. If the recovery requires reconstructing the server/OS, plan the supported full-server/bare-metal path. A backup of an RODC cannot be used to recover a writable DC.

Keep more than one viable writable-DC backup per domain. Otherwise an unusable backup or newly discovered compromise can leave you without a choice. The newest technically consistent backup may already contain the changes you’re trying to undo. Choose the latest trusted state based on when the failure or compromise happened. Microsoft’s backup selection guidance describes those restrictions.

The current guide calls for regular backups of at least two writable DCs in each domain. It also states that, when Recycle Bin is enabled, backup lifetime is the lesser of msDS-DeletedObjectLifetime and tombstoneLifetime. Retention settings are therefore part of media selection, not merely cleanup housekeeping. Compare the actual values and the feature state with the backup’s date; do not substitute a generic 180-day assumption.

During a rehearsal, time the whole job: getting the media and decryption key, reaching independent management tools, provisioning the server, restoring it and checking the required services. Unavailable domain credentials or BitLocker Network Unlock can stop the team before the database restore even begins. The recovery guide covers that first-DC network-unlock dependency.

A recovery plan must work without production AD

Before a rehearsal, establish how the recovery team will obtain:

• Backup media, decryption keys and the last known safe recovery point.
• DSRM credentials and administrative access to the recovery hosts.
• DNS, storage, networking and virtualization access without relying on the failed forest.
• One recoverable writable DC backup per domain, plus the required system and application dependencies.
• A recovery network isolated from production and from compromised DCs.

The sequence and cleanup steps depend on the failure. For compromise, a technically valid backup can still contain the attacker’s changes. Determine the safe point with incident evidence. Microsoft’s forest recovery guide is the procedure to adapt and rehearse, including credential resets and redeployment of remaining DCs.

Give each recovery phase an acceptance gate

Use these checks alongside the forest recovery sequence and the procedures for your environment. Keep potentially contaminated old DCs disconnected while you decide which recovered systems can be trusted.

Restoring the directory also rolls back account and password changes made after the recovery point. Machines, services or external trusts may retain newer credentials. Plan their reconciliation instead of interpreting every subsequent secure-channel error as a failed restore.

DSRM credentials are local to each DC

The DSRM password does not replicate as an ordinary domain account password. Know which credential belongs to which DC and how it will be retrieved during recovery.

For a deliberate password change on an accessible DC, an elevated administrator can use the interactive prompt rather than putting a password in a command line:

ntdsutil "set dsrm password" "reset password on server dc1" quit quit

Synchronizing DSRM from a shadow domain account is an older management technique, not an automatic password policy. Windows LAPS can manage DSRM on supported DCs with the required schema, policy, permissions and encryption prerequisites. Windows LAPS deployment guidance covers the prerequisites; the architecture guide covers DSRM storage and disaster recovery. Rehearse retrieval when every DC in the domain is unavailable.

Test the result, not only the restore operation

Once the restore finishes, check advertising, DNS, the chosen FSMO roles, directory replication, SYSVOL/NETLOGON, authentication and representative applications. Make sure the recovery team can administer the environment too. Record how long it took and where a missing person or service held things up.

Do not reconnect a restored test forest to production. Stale replication references and duplicated directory identities can turn a rehearsal into another incident. Test recovery networking, outbound access and management isolation explicitly.