Active Directory / Advanced / Lesson 15

Backup and forest recovery

Distinguish replication, object recovery, and forest recovery, then evaluate trusted backup evidence without restoring a controller or handling recovery credentials.

About 5 min readContent reviewed 2026-10-26

On this page

Lesson goals

Explain why replicas and snapshots are not a complete recovery plan.
Separate backup freshness, trustworthiness, and tested recoverability.
Plan recovery authority, isolation, dependencies, and verification.

Define what must be recovered and from which threat

A deleted object, one failed controller, a corrupted policy component, and a compromised forest are different recovery scenarios. Replication can distribute an unwanted change, so another replica is not automatically a clean backup. A virtual-machine snapshot is not a substitute for an AD-aware supported backup and restore plan. The recovery point objective and recovery time objective describe business needs, not evidence that a backup is safe or usable. Record which domains, directory components, SYSVOL, DNS, keys, and application dependencies the plan covers. Keep recovery ownership and emergency access controlled without putting secrets into course examples or ordinary logs.

Do not choose only the newest declared file

The complete Python fixture filters synthetic backup labels by two declared evidence flags: known safe and restore test documented. It intentionally rejects a newer suspect backup. These flags are assumptions supplied to the model, not claims that any backup was actually created, inspected, or restored. Real trust requires investigating when corruption or compromise began and whether the selected backup is compatible with the supported recovery scenario. Backup age and directory object-retention limits need their applicable policy and product guidance; do not invent a universal validity period. A local candidate list cannot authorize restoring a domain controller.

python Offline declared-backup eligibility model

backups = [
    {"id": "backup-a", "time": 1, "known_safe": True, "restore_test_documented": True},
    {"id": "backup-b", "time": 2, "known_safe": False, "restore_test_documented": True},
    {"id": "backup-c", "time": 3, "known_safe": True, "restore_test_documented": False},
]
candidates = [item["id"] for item in backups if item["known_safe"] and item["restore_test_documented"]]
print(candidates)

Expected output

['backup-a']

Only backup-a meets both modeled conditions. No backup content, Windows image, directory database, or recovery credential is accessed.

Recovery type determines the supported procedure

System-state recovery, full-server recovery, object recovery, and forest recovery have distinct support and sequencing requirements. AD Recycle Bin, when appropriately enabled and applicable, can help particular deleted-object scenarios but is not a forest backup. An RODC backup cannot simply stand in for a writable-controller recovery. Hardware/OS context and the original backup type matter, so do not improvise a system-state restore onto any new installation. Authoritative directory or SYSVOL recovery changes which state is propagated and needs a carefully justified source. The course provides no operational sequence for seizing roles, resetting secrets, editing attributes, or restarting replication. Use the applicable official recovery runbook under authorized ownership.

Keep restored trusted state away from an untrusted source

Forest recovery may require strong isolation so unsafe data or surviving compromised controllers do not contaminate the recovered environment. That is an incident/recovery decision, not a classroom network operation. The contextual record lists plan components and an approval gate, not executable steps. Include communication, service dependencies, trusted installation media, backup protection, recovery access, validation, and controlled reintroduction. A plan that only says restore the latest VM is incomplete. Test the authorized procedure with synthetic isolated infrastructure, record actual outcomes, and protect the recovery documentation because it can reveal highly sensitive control-plane details.

json Non-runnable recovery-readiness record

{"scenario":"synthetic-forest-recovery-review","backup_selection":"requires_trust_and_supported_restore_evidence","isolation":"approved_recovery_environment","coverage":["directory","SYSVOL","DNS","service_dependencies"],"execution":"not_authorized_by_this_plan"}

The record documents required decisions without selecting real backups or initiating any restore, role change, or replication operation.

Prove recoverability with the right evidence

A successful backup job does not prove supported restoration, policy consistency, authentication, application dependencies, or acceptable recovery time. A recovery exercise should verify those required outcomes in an authorized isolated environment, including denied access and known-good identity state. Preserve the exact versions, selected backups, timing assumptions, and exceptions. Review recovery readiness after schema, functional-level, service, or security changes. Never reconnect a restored controller to a live forest as an unreviewed test. This lesson validates only local candidate filtering and distinguishes that arithmetic from every real recovery action, which remains unexecuted.

Common errors and fixes

The newest backup is automatically called clean.

Why it happens: Freshness was confused with trustworthy recovery state.
How to fix it: Establish the incident timeline and supported known-good evidence.
Prevent it next time: Record backup trust and restore-test evidence separately.

Replication is treated as protection from unwanted directory changes.

Why it happens: Availability copies were mistaken for historical recovery.
How to fix it: Maintain a supported protected backup and recovery design.
Prevent it next time: Test deletion and compromise scenarios explicitly.

A restored controller is reconnected without review.

Why it happens: Isolation and reintroduction were omitted from recovery planning.
How to fix it: Follow the authorized applicable forest recovery procedure.
Prevent it next time: Require a recovery-owner approval gate.

Check your understanding

1. Mark backup-c restore_test_documented True. What does the candidate list prove and what dangerous conclusion must be avoided?

Show worked solution

The model now lists backup-a and backup-c because both declared flags are true. It still has not examined a backup, validated the evidence, selected a supported recovery type, or proven the newest candidate safe for the actual incident. The flags require independent authorized evidence. Do not treat changing a Boolean as performing or approving a recovery test.

2. An organization can restore one object but has never rehearsed forest recovery. Explain the gap without prescribing a live restore.