# Backup & Recovery

> Authoritative vs. non-authoritative Restore, Objekt-Recovery über den AD-Papierkorb, der Forest-Recovery-Ablauf und die Fallen von USN-Rollback und Snapshot-Reverts.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/backup-recovery  
Stand: 2026-07-26  
Interaktiver Teil: 7 Checks (nur im Browser)

## Backup & Recovery: Restore-Modi, Objekt-Recovery und Forest-Wiederherstellung

### Replikation ist kein Backup

AD repliziert **Multi-Master**: jede Änderung an einem DC wandert automatisch zu allen anderen. Das schützt gegen **Hardware-Ausfall** eines einzelnen DC — aber **nicht** gegen einen logischen Fehler.

Löscht jemand versehentlich eine OU mit hunderten Konten oder korrumpiert ein fehlerhaftes Skript Attribute, dann repliziert AD diesen Schaden **zuverlässig auf alle DCs**. Zehn Domain Controller machen die Löschung nur zehnfach vorhanden, nicht rückgängig.

> **Merksatz:** Redundanz schützt gegen **Ausfall**, Backup gegen **Fehler und Korruption**. Nur ein AD-fähiges **System-State-Backup** je Domäne — regelmäßig getestet — deckt logische Schäden und den Totalverlust ab.

### Authoritative vs. non-authoritative Restore

Wird ein DC aus einem Backup zurückgespielt, entscheidet der **Restore-Modus**, was mit den wiederhergestellten Objekten passiert:

|  |  |
| --- | --- |
| **Non-authoritative** | Der DC kommt mit altem Stand hoch und lässt sich von den anderen DCs **auf den aktuellen Stand nachführen**. Das ist der Normalfall, um einen **ausgefallenen DC** wieder einzureihen. |
| **Authoritative** | Ein Objekt/eine Teilstruktur wird mit **erhöhter Versionsnummer** markiert, sodass sie sich beim Replizieren gegen alle anderen DCs **durchsetzt** — nötig, um versehentlich **Gelöschtes zurückzuholen**. |

> **Kernmissverständnis:** Ein **non-authoritative** Restore holt gelöschte Objekte **nicht** zurück: Die anderen DCs kennen den „gelöscht“-Zustand mit höherer Version und **re-replizieren die Löschung** sofort wieder auf den frisch zurückgespielten DC. Zum Zurückholen brauchst du **authoritative** (oder den Papierkorb).

### Objekt-Recovery: drei Wege, zwei Fallen

Für ein einzelnes gelöschtes Konto gibt es drei Optionen — mit sehr unterschiedlichem Ergebnis:

|  |  |
| --- | --- |
| **AD-Papierkorb (Recycle Bin)** | Stellt das Objekt mit **allen** Attributen wieder her — auch **link-valued** wie Gruppenmitgliedschaften — und mit **derselben SID**. Muss vorab aktiviert sein (irreversibel). Der saubere Weg. |
| **Tombstone-Reanimation** | Belebt den „Grabstein“ wieder, aber **link-valued Attribute (Gruppen) und geleerte Attribute sind weg** und müssen manuell rekonstruiert werden. Notlösung ohne Papierkorb/Backup. |
| **Neu anlegen** | Erzeugt eine **neue SID**. Alle über die alte SID vergebenen Zugriffe (ACLs, Profile, Postfach) sind **verloren** — auch wenn der Name identisch ist. |

> **Merksatz:** Die **SID** ist die Identität, nicht der Name. Wer neu anlegt, baut einen Namensvetter ohne Rechte. Wer reanimiert, verliert die Gruppen. Der Papierkorb behält beides — deshalb **vor** dem ersten Störfall aktivieren.

### USN-Rollback: warum man einen DC nicht „zurückspult“

Jeder DC nummeriert seine Änderungen fortlaufend über die **USN (Update Sequence Number)** und identifiziert seine Datenbank-Instanz über eine **Invocation-ID**. Die anderen DCs merken sich „von diesem Partner habe ich bis USN *n* gesehen“.

Setzt du einen DC per **VM-Snapshot** oder Image auf einen älteren Stand zurück — ohne AD-fähigen Restore — kann seine USN hinter das fallen, was die Partner schon gesehen haben. Er würde USNs erneut verwenden, die Partner aber für „schon repliziert“ halten. Ergebnis: **USN-Rollback** mit Replikationsdivergenz. Unterstützte AD-Versionen erkennen diesen Zustand typischerweise und halten die Replikation an (mit passenden Ereignissen); darauf darfst du dich nicht als Recovery-Mechanismus verlassen.

> **Ausnahme:** Ab Windows Server 2012 kann ein virtueller DC auf einem Hypervisor mit **VM-GenerationID**-Unterstützung einen Snapshot-Revert **erkennen**: Die GenerationID ändert sich, der DC setzt seine Invocation-ID zurück und meldet sich sauber — ein USN-Rollback wird so vermieden. Ohne diese Plattformunterstützung ist ein Snapshot-Revert **nicht unterstützt**.

### Tombstone Lifetime & Lingering Objects

Gelöschte Objekte werden nicht sofort entfernt, sondern als **Tombstone** aufbewahrt — für die **Tombstone Lifetime (TSL)**. In neu erstellten Forests mit aktuell unterstützten Windows-Server-Versionen sind das typischerweise 180 Tage; bestehende Forests können einen anderen, auch historischen oder bewusst konfigurierten Wert haben. Danach räumt die Garbage Collection den Grabstein endgültig weg.

War ein DC **länger als die TSL offline**, hat er die Löschungen nie mitbekommen und die Grabsteine sind auf den anderen DCs bereits weggeräumt. Verbindest du ihn jetzt einfach wieder, „kennt“ er Objekte, die überall sonst gelöscht sind — **Lingering Objects**. Sie können sogar re-repliziert werden und tote Konten oder Gruppen zurückbringen.

> **Merksatz:** Ein zu lange offline gewesener DC wird **nicht** einfach wieder verbunden und die TSL wird **nicht nachträglich erhöht** (die Grabsteine sind schon weg). Richtig: tatsächliche TSL und Replikationslage prüfen, Lingering Objects nach einem unterstützten Verfahren bereinigen oder den DC kontrolliert ersetzen — und **Strict Replication Consistency** nicht aus Bequemlichkeit abschalten.

### Forest Recovery: der geordnete Ablauf

Ist der **ganze Forest** zerstört oder kompromittiert (z. B. Ransomware, ein manipulierter Schema-/Domänen-Zustand), hilft kein einzelner Restore. Microsofts **Forest-Recovery**-Leitfaden gibt einen strikten Ablauf vor — die Kernidee: **Vertrauen wiederherstellen, bevor irgendein DC wieder ans Produktionsnetz kommt.**

DCs isolieren → 1. schreibbaren DC je Domäne aus geprüftem Backup (non-auth) restoren → Metadaten der übrigen DCs bereinigen + FSMO seizen → **krbtgt (2×), Computerkonto- & Trust-Passwörter zurücksetzen** → Global Catalog & DNS neu aufbauen, Replikation verifizieren → übrige DCs frisch neu aufsetzen & einreihen

> **Warum krbtgt zweimal:** Das `krbtgt`-Konto signiert alle Kerberos-Tickets. Bei Kompromittierung muss sein Passwort **zweimal** zurückgesetzt werden, weil AD die **letzten zwei** Passwörter in der History akzeptiert — ein einmaliger Reset ließe das alte, möglicherweise dem Angreifer bekannte Geheimnis noch gelten.

### Zusammenfassung — gleich im Check

Du kennst jetzt die Achsen: **authoritative vs. non-authoritative Restore**, die drei Wege der **Objekt-Recovery** (Papierkorb/Reanimation/Neuanlage), die **USN-Rollback**-Falle bei Snapshot-Reverts, **Tombstone Lifetime & Lingering Objects**, den geordneten **Forest-Recovery**-Ablauf und warum **Replikation kein Backup** ist.

> **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete Störfälle selbst den richtigen Recovery-Weg — und siehst pro Option, **warum** sie trägt oder aus welchem konkreten Grund sie Daten oder Vertrauen zerstört.

## Quellen

- Microsoft Learn — AD Forest Recovery Guide (Übersicht und geordneter Ablauf)
- Microsoft Learn — AD Forest Recovery: Perform initial recovery (non-authoritative Restore des ersten DC, Metadaten-Cleanup, FSMO seizen, RID-Pool)
- Microsoft Learn — AD Forest Recovery: Reset the krbtgt password (zweifacher Reset wegen Passwort-History = 2)
- Microsoft Learn — Introduction to Active Directory Domain Services (AD DS) Virtualization (VM-GenerationID, USN-Rollback-Schutz)
- Microsoft Learn — USN and USN Rollback (Ursache, stille Divergenz, Quarantäne)
- Microsoft Learn — Introducing the Active Directory Recycle Bin (Erhalt von link-valued und non-link-valued Attributen)
- Microsoft Learn — Outdated Active Directory objects generate event ID 1988 (Lingering Objects, Strict Replication Consistency)
- Microsoft Learn — Active Directory Recycle Bin overview
- Microsoft Learn — AD Forest Recovery guide
- Microsoft Learn — Advanced AD DS management using AD Administrative Center
- Microsoft Learn — AD Forest Recovery: Perform initial recovery
- Microsoft Learn — Active Directory Domain Services backup and restore guidance
- Microsoft Learn — Introduction to Active Directory Domain Services virtualization
- Microsoft Learn — USN and USN rollback
- Microsoft Learn — How to detect and remove lingering objects in an AD DS forest
- Microsoft Learn — Manually remove lingering objects on outdated replication partners
- Microsoft Open Specifications — Tombstone Lifetime and Deleted-Object Lifetime
- Microsoft Learn — AD Forest Recovery: Determine how to recover the forest
- Microsoft Learn — AD Forest Recovery: Reset the krbtgt password