Seit Windows Server 2008 (also Kernel 6.0.x) ist die Komponente Windows Image Backup (Windows Server-Sicherungsfeatures) im Betriebssystem integriert. Dies gilt auch für die Client-Versionen Windows Vista und Windows 7. Während die Funktion bei den Client-Betriebssystemen bereits vorinstalliert ist (Windows-Sicherung), muss das Feature auf einem Server zwar erst installiert werden, gehört aber eben zum Lieferumfang. Das Programm ermöglicht die vollständige Sicherung des Systems auf einen externen Datenträger (bspw. eine USB-Festplatte) oder eine Freigabe im Netzwerk. Bandlaufwerke werden nicht unterstützt. Das Programm eignet sich eingeschränkt für eine regelmäßige Datensicherung – für Disaster-Recovery-Zwecke ist es aber nahezu perfekt. Auf einem Client-Betriebssystem – wie etwa Windows 7 – kann ich den Einsatz als Backup-Programm wiederum empfehlen, handelt es sich auf einem solchen System oftmals doch um geringere Datenmengen.

Installation

Wer das Feature installiert, sollte auch gleichzeitig die Befehlszeilentools auswählen. Dahinter verbirgt sich das Kommandozeilen-Tool wbadmin, mit dem eine Skript-basierte Sicherung möglich wird.

Nach der Installation kann man über die grafische Konsole (Start, Programme, Verwaltung, Windows Server-Sicherung) eine Einmalsicherung durchführen, einen Sicherungszeitplan erstellen oder Wiederherstellungsoptionen wählen. Die grafische Konsole und ihre Funktionen unterscheidet sich bei der Server- und der Client-Version, ich gehe hier nur auf die Server-Variante näher ein.

Backup

Voraussetzungen

Typischerweise existiert in einer Serverumgebung immer ein Backupserver, der alle zu sichernden Daten final auf ein Band schreibt – unabhängig von der verwendeten Backupsoftware. Auf diesem Backupserver richtet man auf einem Laufwerk mit entsprechend freier Kapazität einen neuen Ordner ein

[Volume]\Backup

und gibt diesen anschließend im Netzwerk frei (bspw. Freigabename "Sicherungen"). In den Berechtigungseinstellungen der Freigabe wird für den Benutzer "Jeder" der Vollzugriff gesetzt. Im Reiter Sicherheit des Ordners können nun (bspw. innerhalb einer Domäne) die entsprechenden Benutzer (oder Gruppen) mit den erforderlichen Schreibrechten hinzugefügt werden. Anschließend kann auf den zu sichernden Server(n) die neue Netzwerkfreigabe

\\Backupserver\Sicherungen

genutzt werden. Dadurch lassen sich schnell einfache, mehrstufige Sicherungen der Server einrichten.

Hinweis: Während der Erstellung dieses Artikels ist mir durch Hinweise verschiedener Leser (Danke an Nils und Tim) aufgefallen, dass es große Unterschiede zwischen den Versionen der Windows Server-Sicherung von Windows Server 2008 und R2 gibt. Bei Einsatz eines Windows Server 2008 R2 ist die Sicherung nämlich um ein Vielfaches einfacher, da diese einen wesentlich größeren Funktionsumfang bietet. Das Backup wird deswegen für beide Server-Versionen gesondert betrachtet.

Windows Server 2008

Bei der Einmalsicherung hat der Administrator mehrere Optionen zur Auswahl:

Die vollständige Sicherung sichert alle lokalen Laufwerke, während bei der benutzerdefinierten Auswahl Laufwerke ausgeschlossen werden können. Eine Sicherung einzelner Verzeichnisse oder Dateien ist nicht möglich, es werden nur komplette Laufwerke gesichert. Das Systemvolume wird immer dann gesichert, wenn die Option "Systemwiederherstellung aktivieren" genutzt wird. Als Ziel kann entweder ein weiterer Datenträger (kein weiteres Volume auf dem selben Datenträger auf dem sich das Systemvolume befindet) oder die oben beschriebene, neu erstellte Netzwerkfreigabe verwendet werden:

Der Vorteil der Sicherung besteht darin, dass die Betriebssystem-integrierten VSS-Funktionen (Volume Shadow Copy Services) genutzt werden.

Dadurch wird zur Laufzeit ein konsistentes Backup erstellt, dass jederzeit für eine Systemwiederherstellung verwendet werden kann. Auf dem Backupserver wird durch die Sicherung die folgende Verzeichnisstruktur erstellt:

\\[Backupserver]\Backup\WindowsImageBackup\[Server]\Backup [Date][Time]

Der Servername ist dabei der Name des gesicherten Systems. In dem untersten Backup-Ordner befinden sich nach der Sicherung einige XML-Dateien (Konfigurationsdaten) und die Sicherung als VHD-Datei (Virtual Hard Disk). Bei der Sicherung mehrerer, verschiedener Systeme (durchaus auch zur gleichen Zeit) befinden sich unterhalb des Ordners WindowsImageBackup dann die entsprechenden Ordner mit den jeweiligen Servernamen. So gibt es eine zentrale Stelle aller Sicherungsabbilder, die zur Wiederherstellung genutzt und vom Backupserver auf Band gesichert werden können.

Leider lassen sich mit Hilfe des Sicherungszeitplanes beim Windows Server 2008 keine Sicherungen auf Netzlaufwerke planen, es können lediglich lokale Datenträger genutzt werden. Steht kein solcher zusätzlicher Datenträger zur Verfügung bricht die Einrichtung des Zeitplanes mit folgender Fehlermeldung ab:

Doch es gibt Abhilfe in Form eines Skriptes. Ich habe für diese Zwecke ein einfaches Batch (CMD-Datei) geschrieben (Voraussetzung sind die installierten Befehlszeilentools):

@echo off
set logfile=[LOGFILE]
echo Backup-Start: %DATE% um %TIME% Uhr > %logfile%
echo ———————————————————————- >> %logfile%
wbadmin start backup -backuptarget:\\[BACKUPSERVER]\[FREIGABE] -include:c:,d: -allcritical -quiet >> %logfile%
echo ———————————————————————- >> %logfile%
echo Backup-Ende:  %DATE% um %TIME% Uhr >> %logfile%

In dem Skript sind die Variablen [LOGFILE] durch den Pfad und Dateinamen der Protokolldatei zu ersetzten – sofern benötigt. Die Variablen [BACKUPSERVER] und [FREIGABE] müssen mit dem Namen des Zielservers und dessen Freigabe ersetzt werden. Außerdem müssen die Laufwerksbuchstaben nach der -include Option entsprechend dem jeweiligen System angepasst werden (Komma-getrennt). Der Schalter -allCritical bewirkt, dass automatisch alle Volumes in die Sicherung eingebunden werden, die für eine vollständige Wiederherstellung des Systems benötigt werden (Systemvolume). Das Skript kann nun als Task in der Aufgabenplanung des Servers verwendet werden, um die Systeme bspw. täglich in der Nacht zu sichern.

Windows Server 2008 R2

In der neuen Version der Windows Server-Sicherung des R2 hat sich einiges getan. Im Gegensatz zur alten Version können nun – sowohl bei der Einmalsicherung als auch mit Hilfe des Sicherungszeitplanes – fein granulierte Sicherungselemente ausgewählt werden. Wählt man den "Benutzerdefinierten Konfigurationstyp", so lassen sich in Elemente bis auf Dateiebene zur Sicherung hinzufügen:

Da der Sicherungszeitplan des Windows Server 2008 R2 nun als Zieltyp auch Netzwerkfreigaben unterstützt, wird das obige Skript nicht mehr benötigt. Stattdessen wählt man die zu sichernden Elemente, wie

• Bare-Metal-Recovery
• Systemstatus (wird bei Bare-Metal-Recovery automatisch gewählt)
• Systemvolume (wird bei Bare-Metal-Recovery automatisch gewählt)
• zusätzliche Ordner oder Dateien auf weiteren Volumes

aus. Unter den erweiterten Einstellungen lassen sich dann außerdem noch Ausschlüsse definieren (allerdings nur von Elementen auf zusätzlichen, nicht Bare-Metal-Recovery-relevanten Volumes) und VSS-Einstellungen konfigurieren. Danach kann eine tägliche Sicherungszeit oder auch mehrmalig pro Tag definiert werden:

Der Clou – und damit wesentlicher Vorteil und Unterschied zur Version vom Windows Server 2008 – ist aber, dass als Sicherungsziel nun ein freigegebener Netzwerkordner angegeben werden kann:

Nach der Eingabe der Benutzerauthentifizierung wird die Sicherung eingerichtet und im Hauptfenster des WDS angezeigt:

Windows Server 2008 und R2

Die Dauer einer (initialen) Sicherung ist abhängig von der Größe der Volumes und den installierten Anwendungen, den durchschnittlichen Änderungsdaten der zu sichernden Volumes, der Geschwindigkeit der Festplatten und des Netzwerkes – typischerweise benötigt sie mehrere Minuten. Beschleunigen lässt sich dieses Verhalten aber durch die Aktivierung der Funktion Schattenkopien auf dem bzw. den Quell-Laufwerk(en):

Wird diese Funktion aktiviert, werden diese Schattenkopien für die Sicherung verwendet. Abhängig von der Änderungsrate der Daten auf dem Quell-Laufwerk(en) dauert eine wiederholte Sicherung nur noch wenige Sekunden bis zu einigen Minuten. Eine akzeptable Zeit und eine super Funktion, wie ich finde.

Um Missverständnisse zu vermeiden, sei an dieser Stelle gesagt, dass mit dieser Variante – egal ob Windows Server 2008 oder 2008 R2 – KEINE inkrementellen Sicherungen erstellt werden. Das vorherige Backup wird immer durch die neue Sicherung ersetzt.

Die Version und die Art der Verwendung eines erstellten Backups für die Wiederherstellung kann mit Hilfe des Befehls

wbadmin get version -machine:[Server] -backuptarget:\\[Backupserver]\[Freigabe]

überprüft werden. Die Verwendung des -allcritical Schalters bei der Sicherung bewirkt, dass die Sicherung für ein "Bare-Metal-Recovery" verwendet werden kann:

Recovery

Leider wird – viel zu oft – die Wiederherstellung (in unterschiedlichen Szenarien) von Daten vernachlässigt oder erst gar nicht betrachtet. Dabei bedeutet eine funktionierende Datensicherung nicht, dass im Worst Case ein System innerhalb kürzester Zeit auch wieder betriebsbereit ist. Hier sind ebenfalls mehrstufige Konzepte notwendig und vor allen Dingen zu testen. Für die Windows Server-Sicherung betrachte ich hier den Fall, dass der Server vollständig wiederhergestellt werden muss (Start from scratch oder auch Bare Metal Recovery).

Zu Beginn benötigt man den Installationsdatenträger des ehemals installierten Betriebssystems. Experten können sich auch mit Hilfe des WAIK (Windows Automated Installation Kit) ein eigenes Startabbild erstellen und dieses auf einem WDS-Server via PXE bereitstellen – was den Vorgang deutlich komfortabler und schneller macht. Beim Booten vom Installations-Datenträger muss im Installationsmenü der Punkt Computerreparaturoptionen ausgewählt werden:

Im folgenden Fenster kann man für das betreffende System eventuell benötigte Treiber (bspw. Netzwerk) laden (USB wird unterstützt), um Zugriff auf das Sicherungsabbild im Netzwerk zu erhalten. Da das System "jungfräulich" ist, wird hier logischerweise kein installiertes Betriebssystem angezeigt.

Anschließend ist die Windows-Complete PC-Wiederherstellung zu starten:

Die erste Warnmeldung kann ignoriert und abgebrochen werden:

Danach wählt man den Punkt "Andere Sicherung wiederherstellen" und wählt unter "Erweitert" den Punkt "Im Netzwerk nach einer Sicherung suchen" aus:

Danach wird das Netzwerk gestartet und eine IP Adresse vom DHCP Server (erforderlich!) empfangen. Anschließend kann das Verzeichnis auf dem Backupserver angegeben werden:

Nun muss man sich noch authentifizieren um Zugriff auf die Sicherung zu erhalten und bekommt im folgenden Fenster die existierenden Sicherungen angezeigt.

Im nächsten Schritt muss noch das (oder die) entsprechende Volume(s) ausgewählt werden, die wiederhergestellt werden sollen.

Zum Abschluss kann man noch entscheiden, ob ein (Ziel-)Datenträger von der Wiederherstellung ausgeschlossen, zusätzliche Treiber installiert, der Computer nach der Wiederherstellung neu gestartet oder ein CHKDSK ausgeführt werden soll.

Achtung: Um böse Überraschung zu vermeiden, eine wichtige Information zur Größe des Zieldatenträgers. Der Datenträger, auf dem die Volumes (System und evtl. weitere) wiederhergestellt werden sollen, darf nicht kleiner sein als der ursprüngliche Datenträger – die Wiederherstellung kann sonst die Partitionsdaten nicht einrichten und meldet einen Fehler. Der umgekehrte Fall funktioniert problemlos.

Die Wiederherstellung dauert abhängig von der Netzwerkgeschwindigkeit und der Größe der Sicherung einige Minuten.

Das System wird im Anschluss neu gestartet. Je nach Einsatz des Servers sind evtl. noch weitere Rücksicherungsschritte notwendig (bspw. durch Backuplösung auf Dateiebene), das System ist aber sofort – mit seiner ursprünglichen Konfiguration – einsatzbereit und nutzbar.

Fazit

Wie schon erwähnt, nutze ich das Feature nur als automatisierte Recovery Option, sie ersetzt keinesfalls eine Backuplösung zum Zwecke der Wiederherstellung einzelner Dateien oder deren Stände. Auf Grund der Möglichkeit der Sicherung eines Systems zur Laufzeit, sowie der extrem schnellen Aktualisierungs-Sicherungen und der Integration im Betriebssystem (Sicherung und Wiederherstellung) bin ich von dem Produkt begeistert. Die Integration in einem mehrstufigen Sicherungskonzept, ist aus meiner Sicht deshalb sinnvoll und funktional. So sichern wir typischerweise Serversysteme immer mehrfach: mit Hilfe der Windows Server-Sicherung zu Recovery-Zwecken und zusätzlich auf Datei-Ebene mit einem weiteren Backup-Produkt. Man sollte immer bedenken: Eine Wiederherstellung kann immer nur dann zügig funktionieren, wenn bereits im Vorfeld verschiedene Faktoren beachtet und getestet wurden.

Verwandte Beiträge:

1. Windows Server Backup verstehen und nutzen
   Windows Server Backup ist das Werkzeug, das seit Windows Server...
2. Windows Server Backup: Einmalsicherung ungleich Sicherungszeitplan
   In Windows Server Backup hat man unter Windows Server 2008...
3. Exchange Server 2007 SP1 und Remote Streaming Backup
   Um eine Exchange Server Datenbank zu sichern, wird in den...

Dahinter steht oft eine ungenaue Vorstellung von den Betriebsmastern. Im Folgenden daher ein paar Hinweise dazu.

Was sind Betriebsmaster?

In der Multi-Master-Replikation von Active Directory ist grundsätzlich jeder Domänencontroller (DC) einer Domäne vollständig schreibberechtigt für die AD-Datenbank. Dabei gibt es gar nicht “eine” Datenbank, sondern jeder DC hat seine eigene, unabhängige Kopie. Diese gleichen alle DCs über ein sehr leistungsfähiges Replikationssystem ab.

Selbstverständlich kann es dabei zu Replikationskonflikten kommen. Im einfachsten Fall haben zwei DCs dasselbe Objekt (z.B. einen User) geändert. Welche Änderung greift nun? Einen Überblick über die Replikation und die Konfliktbehandlung hat Philipp Föckeler vor Kurzem hier gegeben:

[faq-o-matic.net » Active-Directory-Replikation im Detail]
http://www.faq-o-matic.net/2010/08/31/active-directory-replikation-im-detail/

Nun ist diese Form der Konfliktauflösung für “normale” Daten und Vorgänge völlig ausreichend. Es gibt aber ein paar Dinge, die man besser nicht dem “Zufall” überlassen sollte, weil sie zu kritisch für Active Directory sind. Dazu zählen etwa Änderungen am AD-Schema (also der Datenbank-Definition, die festlegt, welche Objekte man überhaupt speichern kann und wie diese beschaffen sein müssen) oder das Erzeugen neuer Domänen. In solchen Fällen entstünde ein undefinierter Zustand, wenn zwei DCs unabhängig voneinander z.B. dieselbe Datenfeld-Definition ändern oder eine neue Domäne mit demselben Namen erzeugten.

Daher sind einige solcher Funktionen nur auf jeweils einem DC in der Domäne bzw. sogar im Forest möglich. Man nennt diese Funktionen “Flexible Single-Master Operations” (FSMO). Der DC, der eine solche Funktion ausübt, ist der “FSMO Role Owner” oder im Deutschen “Betriebsmaster”.

Hier (nochmal) eine kurze Übersicht:

Wie wichtig sind Betriebsmaster?

Die Betriebsmaster sind für den ordnungsgemäßen Betrieb des Active Directory zwingend notwendig. Allerdings ranken sich aus diesem Grund auch einige Mythen um diese Funktionen. Daher hier ein paar nähere Hinweise.

• Wenn eine oder mehrere der Betriebsmaster-Funktionen nicht erreichbar sind, wird AD auf Dauer nicht richtig funktionieren. Wichtig ist dabei der Aspekt “auf Dauer”: Wenn eine solche Funktion nur kurze Zeit offline ist, stellt das in fast keiner Situation ein Problem dar.
• Der Ausfall eines Betriebsmaster-DC stellt also keinen Grund zur Hektik dar! Man hat ausreichend Zeit, die Situation zu bewerten und die nächsten Schritte festzulegen.
• Die Betriebsmaster-Funktionen erzeugen auch in großen Umgebungen keine nennenswerte zusätzliche Last auf den Servern. Es ist nicht nötig, dafür “größere” Serverhardware vorzusehen.
• Aus diesem Grund gibt es auch in fast keiner Umgebung einen Grund, die Betriebsmasterrollen auf mehrere DCs zu verteilen. Es hat sich die Empfehlung eingebürgert, die FSMO-Rollen auf dem DC zu belassen, auf dem sie ursprünglich sind, solange dieser Server nicht außer Betrieb geht.
  Aus Windows-2000-Zeiten gibt es noch Empfehlungen, wie man die Rollen verteilen soll. Diese Empfehlungen sind heute nicht mehr adäquat (sie waren schon unter Windows 2000 für fast alle Umgebungen zu hoch gegriffen).
• Es ist allerdings wichtig, den administrativen Zugang zu Betriebsmaster-Funktionen einzugrenzen. Das gilt aber eigentlich für alle administrativen Funktionen, insbesondere wenn sie AD betreffen.

Wie verwalte ich Betriebsmaster?

Dazu haben wir ein paar ältere Artikel, die immer noch zutreffen:

[faq-o-matic.net » Wie verwalte ich die speziellen Domänencontroller-Rollen?]
http://www.faq-o-matic.net/2005/03/22/wie-verwalte-ich-die-speziellen-domaenencontroller-rollen/

[faq-o-matic.net » Wie kann ich Betriebsmasterrollen offline übertragen?]
http://www.faq-o-matic.net/2004/11/12/wie-kann-ich-betriebsmasterrollen-offlineuebertragen/

Was tun, wenn ein Betriebsmaster ausfällt?

Sollte der DC, der eine (oder besser: mehrere) Betriebsmaster-Rollen hält, ausfallen, so ist das Wichtigste: Ruhe bewahren. Im Wesentlichen gilt es zwei Situationen zu unterscheiden.

1. Handelt es sich um ein vorübergehendes Problem?
   Falls das Problem absehbar innerhalb weniger Tage zu beheben ist, so braucht man einfach gar nichts zu tun außer den ausgefallenen Server zu reparieren. Alle normalen Vorgänge innerhalb der AD-Administration laufen unbeeindruckt weiter: Anmelden, Zugriffsrechte verwalten, neue Objekte erzeugen. Das Wesentliche, das nicht mehr geht: Neue Domänen anlegen (aber wie oft tut man das schon?) und das Schema bearbeiten (was auch nicht häufiger geschieht). In Ausnahmefällen kann es sein, dass man keine neuen Sicherheitsobjekte (User, Gruppen, Computer) mehr erzeugen kann (weil keine neuen RIDs mehr frei sind), aber das tritt erst nach mehreren 100 neuen Objekten auf – auch das dürfte in den meisten Umgebungen nicht innerhalb von wenigen Tagen der Fall sein.
   Sobald der FSMO-Rolleninhaber wieder online ist, funktionieren alle Vorgänge wieder.
2. Handelt es sich um ein bleibendes Problem?
   Ist absehbar, dass der ausgefallene Server nicht wieder online gehen kann – etwa wegen eines kompletten Hardwareschadens –, so plant man in Ruhe die Übertragung der FSMO-Rollen auf einen der anderen DCs. Der eigentliche Vorgang ist in dem oben verlinkten Artikel beschrieben.
   Nach der Rollen-Übertragung auf einen anderen DC entfernt man den “gestorbenen” alten DC aus dem AD (seit Windows 2008 reicht es aus, das Computerobjekt in “Active Directory-Benutzer und –Computer” zu löschen).
   Wichtig: Nun muss man sicherstellen, dass der ausgefallene DC auch nach einer möglichen Reparatur nie wieder online ans Netz geht. Muss man die Maschine doch noch einmal hochfahren, um etwa Daten zu retten, so tut man dies ohne Netzwerkverbindung zum AD. Ist die Hardware repariert, so löscht man die Festplatte und installiert Windows neu – erst dann darf der Server wieder Kontakt zum AD bekommen.

Sollte ich die AD-Datensicherung auf einem Betriebsmaster ausführen?

Nach den obigen Ausführungen dürfte klar sein, dass der Ausfall eines Betriebsmasters keine kritische Situation darstellt. Es entstehen also keine Vorteile daraus, das AD-Backup auf einem Betriebsmaster auszuführen. Man sollte sich einfach an die Grundlinie halten, das AD auf mindestens zwei DCs pro Domäne regelmäßig zu sichern.

In großen Umgebungen mit mehr als zwei DCs ist es sogar empfehlenswert, das AD-Backup gerade nicht auf einem Betriebsmaster zu machen. Dahinter steht folgende Überlegung: Wenn man die Betriebsmasterrolle mal auf einen anderen DC verschiebt und dann ein AD-Backup zurückspielen muss, in dem der Rolleninhaber noch der vorherige Server ist, dann kann es dazu kommen, dass nach dem Restore plötzlich zwei DCs sich für den Betriebsmaster halten. Auch das ist keine unbehebbare Situation, aber man kann sie einfach vermeiden, wenn man die Wahl hat, das Backup auf einem Nicht-FSMO-DC zu machen.

Verwandte Beiträge:

1. Wichtige Betriebsmaster während der Domänenaktualisierung
   Während der Aktualisierung der Active-Directory-Domänencontroller auf Windows Server 2003 nehmen...
2. Wie verwalte ich die speziellen Domänencontroller-Rollen?
   Zwar sind grundsätzlich alle Domänencontroller im Active Directory gleichberechtigt. Doch...

Hier geht’s lang:

[Ask the Directory Services Team : Best practices around Active Directory Authoritative Restores in Windows Server 2003 and 2008]
http://blogs.technet.com/askds/archive/2010/03/30/best-practices-around-active-directory-authoritative-restores-in-windows-server-2003-and-2008.aspx

Verwandte Beiträge:

1. Video-Tutorial: Active Directory Object Recovery
   Hinweis: Bei den hier verlinkten Videos handelt es sich (weitgehend)...
2. Werding v2 (English version): Online data recovery for Active Directory
   This is the English version of my Active Directory recovery...
3. Was muss ich beim DNS für Active Directory beachten? (Reloaded)
   DNS ist eines der wichtigsten Themen im Zusammenhang mit Active...

So weit, so schön. Nun fragen sich viele beim Blick auf Ihren Windows 2008 Domänen-Controller: "Wo ist denn nun der angekündigte AD-Papierkorb? Man sieht ja gar nichts!"

Tatsache ist:

• Beim AD Recycle Bin handelt es sich nicht um eine Erweiterung, die man als "Papierkorb" in den grafischen Admin-Utilties sieht, es ist lediglich ein technische Feature, das die Objekte im altbekannten Container "Deleted Objects" komplett wiederherstellbar macht. Dieser versteckte Systemorder befindet sich in jeder Active-Directory-Partition in der Root, lässt sich aber in den Standard-Utilities (z.B. Active Directory Users and Computers, ADSI Edit) nicht anzeigen.
• Das AD Recycle Bin ist standardmäßig deaktiviert, man muss also zuerst Hand anlegen, bevor man gelöschte Objekte ohne großen Aufwand wiederherstellen kann. Die Aktivierung des AD-Recycle-Bin-Features gelingt übrigens nur, wenn der Functional Level des gesamten AD-Forests auf Windows Server 2008 R2 steht, es müssen also alle DCs im Forest mindestens mit Windows Server 2008 R2 laufen. Einmal aktiviert, stehen die Möglichkeiten des AD Recycle Bin im gesamten Forest zur Verfügung.
• Es gibt für Objekte im Recycle Bin nun zwei verschiedene Zustände: "Deleted" und "Recycled". Lediglich im Zustand "Deleted" können Objekte noch zurückgeholt werden, Sie verbleiben danach als "Recycled"-Objekte nur noch zum Zweck der internen AD Replikation in der Datenbank, bevor sie endgültig verschwinden:

  

Es existieren die beiden Werte msDS-deletedObjectLifetime und tombstoneLifetime, die die Aufenthaltsdauer der Objekte im Deleted-Objects-Container steuern. In einer reinrassigen (sprich neu installierten) Windows-2008-R2-Umgbung sind beide Werte standardmäßig auf 180 Tage gesetzt.

In einem AD Recycle Bin Artikel im Technet sind alle entsprechenden Details dargelegt, hier wird auch beschrieben, wie der AD Recycle Bin mit Powershell-Befehlen aktiviert wird und wie man dann mit Get-ADObject und Restore-ADObject die Wiederherstellung in der Power Shell durchführt.

Dieses Verfahren ist jedoch recht umständlich, wenn z.B. aus Versehen ein OU mit Unter-OUs und vielen Objekten darin gelöscht wurde. Dann muss man diese Objekte nämlich umständlich identifizieren (wer schüttelt schon schnell mal einen Get-ADObject-Filter aus dem Ärmel, der alle Objekte umfasst, die innerhalb der letzten Stunde gelöscht wurden?) und dann wiederherstellen, aber bitte die gelöschten OUs zuerst, denn Restore-Object kann zusammen mit Objekten nicht automatisch ihre ebenfalls gelöschten darüber liegenden Container wiederherstellen.

All dies hat mich dazu bewogen, ein kostenloses grafisches Utility zu entwickeln, das den bequemen Zugriff auf den "Deleted Objects"-Container, die Wiederherstellung der gelöschten Objekte und die Aktivierung/Konfiguration des AD-Recycle-Bin-Features erlaubt: LAZARUS.

Die LAZARUS Version 1.0.1 steht hier zum Download zur Verfügung. Ursprünglich war Lazarus ein Ableger meines kommerziellen LDAP Browsers "LEX – The LDAP Explorer" – in beiden werkelt die gleiche Browser-Engine unter der Motorhaube.

LAZARUS kann nun Folgendes:

• Den Deleted-Objects-Container und dessen Inhalt anzeigen (falls dieser nicht zu sehen ist: In manchen Umgebungen kann nur der vordefinierte Administrator auf den Deleted-Objects-Container zugreifen, obwohl eigentlich eine Mitgliedschaft in den 'Administratoren' der Domäne ausreichen sollte!)
• Die gelöschten Objekte können bequem einzeln oder alle in einem Schritt per Mausklick an ihrem ursprünglichen Platz oder an einem anderen Container wiederhergestellt werden.
• Soll ein Objekt wiederhergestellt werden, dessen beherbergender Container auch gelöscht wurde, so wird dieser automatisch auch wiederhergestellt.
• Das ganze klappt auch für AD-LDS-Umgebungen – LAZARUS kommt mit einem entsprechenden Dialog zum Aufbau von LDAP Connections zu beliebigen AD-Systemen (auch Domänen- oder Forest-übergreifend).
• Ist der AD Recycle Bin nicht aktiv, dann kann er mit LAZARUS per Mausklick aktiviert werden (dazu braucht man jedoch Schreibrechte in der AD Configuration Partition, muss also Enterprise-Admin sein)
• Alle Werte, die bestimmen, wie lange die gelöschten Objekte im Deleted-Objects-Container verharren und wiederherstellbar sind, können bequem überprüft und gesetzt werden.
  

Einige wichtige technische Informationen zu LAZARUS:

LAZARUS läuft unter Windows XP, Vista, Windows 7, Windows Sever 2003, Windows Server 2008 (und den jeweiligen R2-Fassungen). Eine explizite Installation von Binaries oder DLLs ist nicht notwendig, kopiert einfach die ausführbare LAZARUS-Datei auf ein lokales Laufwerk und startet die Applikation.

Technische Voraussetzung: .NET Framework 2.0 Runtime Environment. Die Laufzeitumgebung .NET Framework ist auf jedem Windows Vista, Windows 7 oder Windows Server 2008 bereits vorhanden, so dass Ihr hier LAZARUS verwenden können, ohne vorher .NET installieren zu müssen. Beachtet hierbei, dass die Betriebssysteme auf den neuesten Stand mit allen Hotfixes aktualisiert werden müssen, um über die passende .NET-Framework-Version zu verfügen.

Für Fragen und Anregungen bezüglich LAZARUS stehe ich gerne zur Verfügung, einfach das LAZARUS-Forum in der LEX Online Community verwenden.

Verwandte Beiträge:

1. Welchen Wert soll man der „Deleted Object Lifetime“ zuweisen?
   Eine Frage aus den englischsprachigen Microsoft Newsgroups (sinngemäß): Gibt es...
2. Dynamische Objekte in AD: Unbekannt und gefährlich
   Es ist weithin unbekannt, dass Active Directory bereits seit Windows...
3. Wie stelle ich das AD wieder her?
   Grundsätzlich ist ein Restore des AD in einer richtig aufgebauten...

Oops!Backup wurde in c’t 2/2010 vorgestellt. Gemeinsam mit dem Hersteller Altaro verlosen wir 25 Lizenzen der Software, die Benutzerdaten unter Windows XP bis Windows 7 sichern und sehr komfortabel versionsweise wiederherstellen kann. Die Verlosung läuft von unserem Geburtstag am 1. Februar 2010 an für fünf Wochen, und jede Woche gibt es fünf Lizenzen für euch. Schaut also regelmäßig hier vorbei!

Ab dem 1. Februar 2010 findet ihr das Teilnahmeformular hier bei uns.

Hier die Pressemitteilung von faq-o-matic.net und Altaro zum Thema:

Verwandte Beiträge:

1. 25 Backup-Lizenzen zu gewinnen
   Wie schon vor einigen Tagen angekündigt: Zu unserem 5. Geburtstag...
2. Betatest: Altaro Hyper-V Backup
   Der Software-Hersteller Altaro, bekannt für sein Client-Backuptool “Oops!Backup”, wird in...
3. Hyper-V-Backup mit Altaro
   Vor einigen Wochen haben wir über die Betaphase einer Backuplösung...

Gibt es eine Empfehlung, welchen Wert man der ‚Deleted Object Lifetime‘ zuweisen soll? Gibt es Pros und Contras zu größeren/kleineren Werten?

Seit Windows Server 2008 R2 besitzt Active Directory eine Papierkorb-Funktion. Der Papierkorb hilft, gelöschte Objekte ohne viel händische Arbeit wiederherzustellen. Der Mehrwert des Papierkorbs ist, dass beim Löschen eines Objektes alle Attributewerte erhalten bleiben – dies war bisher nicht der Fall. Active Directory leert per Vorgabeeinstellung eine Mehrzahl an Attributen bei der Löschung, was ein direktes Wiederherstellen aus dem Container „Deleted Objects“ schwierig macht.

Die „Deleted Objecte Lifetime“ ist die Zeit, in der ein Objekt im Papierkorb mit all seinen Attributen verweilt, bevor es „recycled“ wird und – wie bekannt – von der Mehrzahl seiner Attribute getrennt wird. Der Recycle-Zustand entspricht also dem „Tombstone“-Zustand in AD ohne den Papierkorb. Der Papierkorb ist also gewissermaßen eine zusätzliche Zeitspanne _vor_ dem eigentlichen tombstone.

Weiterlesen? Der Originalartikel ist in englischer Sprache auf http://www.frickelsoft.net/blog/?p=235 zu finden.

Verwandte Beiträge:

1. Das Geheimnis der Tombstone Lifetime
   Das Attribut "tombstoneLifetime" im Active Directory bestimmt, wie lange ein...
2. Video-Tutorial: Active Directory Object Recovery
   Hinweis: Bei den hier verlinkten Videos handelt es sich (weitgehend)...
3. Lazarus erweckt gelöschte AD-Objekte bequem wieder zum Leben
   Mit Windows Server 2008 R2 hat Microsoft den Active Directory...

Hinweis: Bei den hier verlinkten Videos handelt es sich (weitgehend) um Mitschnitte meiner Demos bei der ice:2009 in Lingen. Das Thema meiner Session war: “Active Directory Disaster Recovery: So mache ich’s richtig!”.

Wer die Videos zu klein findet, schaut sie sich direkt in unserem Kanal bei YouTube an.

Active Directory (AD) enthält heute eine ganze Reihe von Mechanismen, mit denen sich Datenverluste ausgleichen lassen. Seit dem Erscheinen des AD mit Windows 2000 hat Microsoft diese Mechanismen deutlich ausgebaut, sodass Administratoren einer modernen Umgebung geeignete Mittel bereitstehen, um Objekte wiederherzustellen. Unser Tutorial stellt die wichtigsten Methoden vor, die für alle Windows-Versionen seit Windows 2000 bereitstehen. Dabei konzentrieren wir uns auf Bordmittel und kostenlose Zusatzwerkzeuge.

Was kann denn passieren?

Um die passende Methode für einen Schadensfall auszuwählen, muss zunächst das Szenario feststehen. Mögliche Schäden lassen sich in drei Bereiche aufteilen:

• Verlust eines Domänencontrollers (DC): Ist nur einer von mehreren DCs einer Domäne ausgefallen, so braucht der Administrator normalerweise überhaupt keine Recovery-Methode. AD ist fehlertolerant aufgebaut, sodass die Anmeldedienste weiterlaufen, solange mindestens ein DC in der Domäne korrekt arbeitet. Um die ausgefallene Maschine zu ersetzen, reicht es – bezogen auf AD – aus, einen neuen Server zu installieren und ihn mit “dcpromo” zum DC hochzustufen. Die AD-Replikation sorgt dann dafür, dass der neue DC innerhalb weniger Minuten voll funktionsfähig ist.
• Verlust aller DCs einer Domäne: In diesem Fall benötigt der Administrator selbstverständlich eine vollständige Datensicherung seines AD, um die Domäne auf neuer Serverhardware (auch virtuell möglich) wiederherzustellen. Daher empfiehlt es sich, regelmäßig (z.B. täglich) mindestens einen DC zu sichern, besser aber mehrere. Für das Backup nutzt man hier den “System State”, den alle für Windows-Server geeigneten Backupprogramme sichern können. Den Backup- und Restore-Vorgang beleuchten zwei unserer Videos.
  Sonderfall: Forest Recovery. Wer einen AD-Forest mit mehr als einer Domäne betreut, muss im Fall des Komplettverlusts alle Domänen wiederherstellen. Für jede Domäne nutzt man dabei das “normale” Restore-Verfahren (Non-authoritative Restore). Wichtig: Die Wiederherstellung verläuft von “oben” nach “unten”, also beginnend bei der Root-Domäne des Forest. Hierzu gibt es ein sehr gutes Whitepaper bei Microsoft, das im Wesentlichen auf alle AD-Versionen zutrifft:

[Planning for Active Directory Forest Recovery]
http://technet.microsoft.com/en-us/library/cc786327(WS.10).aspx

[Download details: Best Practices: Active Directory Forest Recovery]
http://www.microsoft.com/downloads/details.aspx?FamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE&displaylang=en

• Verlust einzelner Objekte: Dieser Fall ist der eigentlich interessanteste und bei weitem der häufigste. Der Administrator hat Objekte aus der Domäne gelöscht oder überschrieben, die er nun wiederherstellen muss. Hierfür bietet AD je nach Version unterschiedliche Methoden, die wir im Folgenden und in unseren Videos beleuchten.

Den Rahmen für unsere Videos bildet die Präsentation von der ice:2009, die ihr bei uns herunterladen könnt:

[faq-o-matic.net » ice:2009: AD-Recovery – die Folien]
http://www.faq-o-matic.net/2009/08/22/ice2009-ad-recovery-die-folien/

Backup des System State

Grundlage für ein Recovery-Konzept ist stets das Backup des System State, das man bei Bedarf um weitere Methoden ergänzen kann. Der “System State” ist eine vordefinierte Schnittstelle des AD, die immer nur vollständig genutzt werden kann. Sie umfasst die AD-Datenbank, aber auch die Konfiguration des Servers. Daher ist der System State leider hardwareabhängig. Es empfiehlt sich daher, den System State immer von aktueller Hardware zu sichern, die man im Fall des Falles leicht ersetzen kann. Auch das Sichern von einem virtuellen DC ist empfehlenswert, weil die Virtualisierung eine gewisse Unabhängigkeit von konkreter Hardware ermöglicht und damit Treiberprobleme beim Recovery vermeidet.

Um nicht nur von einem Backup abhängig zu sein, empfehlen die meisten Experten, mehr als einen DC regelmäßig zu sichern. Ob es sich bei diesen DCs um die Inhaber der Betriebsmasterrollen (FSMO) handelt, ist hingegen nicht wichtig, weil diese Rollen sich im Zweifel leicht auch nachträglich verschieben lassen.

Unter Windows 2000 und 2003 reicht das mitgelieferte NTBackup völlig für die System-State-Sicherung aus. Ab Windows Server 2008 gibt es NTBackup nicht mehr. Auch das dort vorhandene Windows Server Backup eignet sich für die Sicherung des System State, jedoch muss man hier prüfen, wie und auf welches Medium man genau sichert. Das Internet bietet ausreichend Anleitungen dafür.

Eine zusätzliche Empfehlung kommt von uns: Damit man im Fall des Falles die gelöschten Objekte überhaupt identifizieren kann, sollte man beim Backup auch einen Textexport des AD anfertigen und diesen mitsichern. Dazu eignet sich das folgende Kommando:

csvde –f C:\Daten\AD-Export.txt –u –l sAMAccountName,objectClass,description

Unser Video beschreibt den gesamten Vorgang unter Windows Server 2003 R2; im Prinzip funktioniert er aber in allen Windows-Versionen sehr ähnlich.

Non-Authoritative Restore

Das Restore von einem System State Backup beginnt stets als “Non-Authoritative Restore”. Hiermit setzt man das AD auf einem DC auf den gesicherten Stand zurück. Ist dieser DC nach dem Restore der einzige der Domäne (etwa nach einem Komplettausfall aller DCs), so ist man nach diesem Schritt fertig. AD sollte wieder laufen. Für die nötige Redundanz kann man danach weitere DCs über das normale dcpromo-Verfahren einbinden.

Authoritative Restore

Aufwändiger ist der Fall, wenn das Restore des System State dazu dient, verlorene Objekte zurückzuerhalten. In Windows 2000 war dies die einzige Methode für das Object Recovery. Seit Windows Server 2003 gibt es zusätzliche Verfahren, doch es gibt auch heute noch Situationen, in denen das Authoritative Restore angesagt ist, z.B. wenn sehr viele Objekte wiederhergestellt werden müssen.

Das Authoritative Restore ermöglicht es, bestimmte Objekte wiederherzustellen oder auf einen früheren Stand zurückzusetzen (z.B. wenn das aktuelle Kennwort unbekannt ist, aber das alte noch verfügbar ist). Der Trick besteht darin, dass man auf einem DC das Backup des AD wiederherstellt. Würde man nun nichts weiter tun, so sorgte die AD-Replikation dafür, dass dieser wiederhergestellte DC auf den aktuellen Stand kommt – also werden die Objekte oder Daten wieder gelöscht, die man eigentlich gerade restaurieren wollte. Daher markiert man direkt nach dem Backup (und vor dem Reboot des DC!) die gewünschten Objekte als “aktuell”.

Genau dieser Vorgang ist das Authoritative Restore: Der Administrator setzt manuell die Seriennummern der betreffenden Objekte hoch, sodass die wiederhergestellte Version in der Replikation als die aktuellste Fassung erkannt wird. Auf diese Weise überschreibt das wiederhergestellte Objekt auf allen anderen DCs das dort gelöschte Objekt bzw. die dort gespeicherten Objektdaten.

Das Werkzeug hierzu ist das Kommandozeilenwerkzeug “NTDSUtil”. Ein Authoritative Restore kann nur auf einem DC erfolgen, der sich im Recovery-Modus befindet – in diesen bootet man manuell, der DC ist also für das Netzwerk in dieser Zeit offline. Den nötigen Vorgang demonstriert unser Video. Auch hier ist das Verfahren unter allen Windows-Versionen seit 2000 praktisch identisch.

Das Verfahren, die Gruppenmitgliedschaften per ldfide.exe wiederherzustellen, beschreibt dieser Artikel:

[Run an LDIF file to recover back-links: Active Directory]
http://technet.microsoft.com/en-us/library/cc786564(WS.10).aspx

Tombstone Recovery

Gelöschte Objekte entfernt AD nicht gleich aus der Datenbank. Um die Replikation auch in großen Umgebungen zu ermöglichen, hält der Verzeichnisdienst stattdessen alle gelöschten Objekte als “Tombstone” (Grabstein) in der Datenbank und repliziert sie für längere Zeit über alle DCs. So ist sichergestellt, dass temporäre Replikationsprobleme nicht dazu führen, dass gelöschte Daten plötzlich wieder auftauchen. Erst nach Ablauf der “Tombstone Lifetime” entfernt jeder DC die Tombstones aus seiner jeweiligen Datenbank. Je nach Umgebung beträgt die Tombstone Lifetime standardmäßig 60 bzw. 180 Tage.

Der Tombstone enthält fast keine Detaildaten mehr, doch die wichtigsten Informationen sind noch vorhanden: Der Objektname, die Security-ID (SID) und einige Replikations-Metadaten. Seit Windows Server 2003 ist es möglich, einen Tombstone wieder in ein ordentliches Objekt zurückzuverwandeln und es damit nach einer Löschung wiederherzustellen.

Leider bringt Windows selbst kein Werkzeug mit, um das Tombstone Recovery auszuführen. Es gibt aber kostenlose Werkzeuge, die das tun, etwa ADRestore von Sysinternals.

[AdRestore]
http://technet.microsoft.com/de-de/sysinternals/bb963906.aspx

Ein wiederhergestellter Tombstone umfasst aber eben nur die Rumpfdaten des Objekts. Zusätzliche Informationen wie Adressdaten, das Kennwort oder Gruppenmitgliedschaften fehlen. Dadurch ist nach dem Recovery stets Handarbeit angesagt. Um diese zu vereinfachen und die wichtigsten Daten (mit Ausnahme des Kennworts) automatisch wiederherzustellen, eignet sich mein Skript-Werkzeug Werding.

[faq-o-matic.net » Active-Directory-Daten online wiederherstellen]
http://www.faq-o-matic.net/2006/11/19/active-directory-daten-online-wiederherstellen/

Unser Video zeigt den Vorgang auf Basis von Windows Server 2003. Er funktioniert ebenfalls in allen Folgeversionen, nicht aber unter Windows 2000.

AD-Snapshots

Seit Windows Server 2008 kann der Administrator Snapshots des AD anfertigen. Dabei handelt es sich um Momentaufnahmen des Datenbestandes. Einen solchen Snapshot kann man als Read-only-Version online verfügbar machen, indem man ihn mit dem Dienstprogramm dsamain.exe als LDAP-Verzeichnis auf einem beliebigen TCP-Port startet. Mit Hilfe der dort nachlesbaren Daten kann man dann “historische” Werte aus dem “alten” AD auslesen, um sie z.B. nach einem Tombstone-Recovery auf die wiederhergestellten Rumpf-Objekte zu übertragen. Zur Nutzung der Snapshots reicht ein einziger DC mit Windows Server 2008 oder höher aus, ein bestimmter Modus des AD ist nicht nötig.

Von Haus aus geht dies aber leider nur manuell. Fredrik Lindström hat daher ein Werkzeug entwickelt, das den aktuellen Stand des AD mit einem Snapshot vergleicht. Das Werkezug ermöglicht es dabei gleich, gelöschte Objekte wiederherzustellen und überschriebene Daten zurückzusetzen. Dieses “Directory Services Comparison Tool (DSCT)” erleichtert den Umgang mit Snapshots ungemein.

[DSCT - Lindström]
http://lindstrom.nullsession.com/?cat=7

Bei der Entwicklung des Programms hat Fredrik einen Bug in Windows Server 2008 gefunden, den Microsoft erst in Windows Server 2008 R2 korrigiert hat (einen Bugfix für 2008 wird es voraussichtlich nicht geben!). Dieser Bug bewirkt, dass der AD-Snapshot eine höhere Seriennummer (Update Sequence Number, USN) hat als das Live-AD. Dadurch sehen die Daten des Snapshots stets neuer aus als die wirklich aktuellen Daten. Als Workaround für diesen Bug kann das DSCT die USNs des Live-AD “gewaltsam” hochzählen. Erst danach sind unter Windows Server 2008 automatische Vergleiche zwischen dem Snapshot und dem AD möglich. (In Windows Server 2008 R2 besteht dieses Problem, wie gesagt, nicht mehr.)

Unser Video demonstriert die Arbeit mit dem DSCT.

Mehr dazu beschreibt unser Artikel zu AD-Snapshots:

[faq-o-matic.net » Windows Server 2008: Snapshots des Active Directory]
http://www.faq-o-matic.net/2007/04/30/windows-server-2008-snapshots-des-active-directory/

AD-Papierkorb

Erst mit Windows Server 2008 R2 hat Microsoft den jahrelang geäußerten Kundenwunsch erfüllt und bietet einen “Papierkorb” im Active Directory an. Damit steht, ähnlich wie in Anwenderprogrammen oder im Dateisystem, eine Möglichkeit zur Verfügung, versehentliche Löschungen rückgängig zu machen.

Dazu führt das AD einen neuen Zustand für Objekte ein, und zwar den Zustand “Recycled Object”. Im Kern verbirgt sich dahinter ein erweiterter Tombstone: Statt wie früher fast alle Daten eines Tombstones zu entfernen, behält AD für einen Tombstone einfach das komplette Objekt bei. Dadurch wächst natürlich in großen Umgebungen der Umfang der AD-Datenbank an – daher ist das Feature standardmäßig auch nicht aktiviert.

Den AD-Papierkorb kann man nur ein-, aber nicht ausschalten. Zudem lässt er sich nur für den gesamten Forest aktivieren, aber nicht für einzelne Domänen. Alle Domänen müssen dabei im Modus “Windows Server 2008 R2” oder höher laufen. Details dazu hat Yusuf Dikmenoglu dargestellt:

[LDAP://Yusufs.Directory.Blog/ - Der Active Directory-Papierkorb im Windows Server 2008 R2]
http://blog.dikmenoglu.de/PermaLink,guid,18ffdd1d-9bad-4ae6-ad21-7e1a9f36d635.aspx

Unser Video zeigt das Aktivieren und das Nutzen des AD-Papierkorbs mit der PowerShell sowie mit einem kleinen kostenlosen Zusatztool.

Hier der Link zu dem Tool “ADRecycleBin”:

[ADRecycleBin]
http://overall.ca/index.php?option=com_content&view=article&id=40&Itemid=66

Erweiterte Überwachung

Windows Server 2008 hat noch eine weitere Funktion eingeführt, die sich zum Wiederherstellen überschriebener Daten eignet: Die erweiterte Überwachung des Verzeichnisdienstes. Aktiviert man sie, so protokolliert ein DC jede Änderung an Attributwerten im Ereignisprotokoll.

Wie bei jeder Windows-Überwachung ist auch diese an zwei Stellen zu konfigurieren: Zunächst schaltet man per Gruppenrichtlinie die Überwachung selbst ein. Das muss auf allen DCs einer Domäne geschehen, sinnvollerweise also über die Default “Domain Controllers Policy” oder ein anderes GPO, das an die OU “Domain Controllers” gebunden ist. Als zweiter Schritt ist die Überwachung bei den jeweiligen Objekten zu aktivieren, also z.B. für eine wichtige OU und deren Unterobjekte. Wie es geht, zeigt unser Video.

Diese Funktion hat allerdings zwei Tücken: Zum einen erzeugt jede einzelne Änderung einen Event-Eintrag – ein geändertes Attribut gleich zwei, einmal fürs Löschen und einmal fürs Schreiben des neuen Wertes. Zum anderen protokolliert nur der ändernde DC diese Daten. Will man also wissen, was geändert wurde, muss man alle DCs der Domäne abfragen. Dies erleichtert übrigens das oben genannte DSCT – ein großer Umstand bleibt es gleichwohl. Dabei sollte man auch beachten, dass so natürlich eine sehr große Datenmenge entsteht. Wer diese Funktion nutzt, muss also gleichzeitig ein Event-Management etablieren, das die Ereignisprotokolle regelmäßig sichert oder exportiert und dann ggf. löscht.

Das richtige Werkzeug

Keine der Backup- und Recovery-Funktionen deckt alle Zwecke ab. Wer für die Wartung einer AD-Umgebung verantwortlich ist, sollte sich also seinen Werkzeugkoffer aus den bestehenden Möglichkeiten zusammenstellen. Dabei können die folgenden Übersichten vielleicht hilfreich sein.

Verfügbarkeit der Methoden

Anwendbarkeit in Szenarien

Verwandte Beiträge:

1. Fallen und Auswege beim Recovery von Active Directory
   Der Microsoft-Supportmitarbeiter Herbert Mauerer hat einen sehr lesenswerten Artikel zum...
2. Werding v2 (English version): Online data recovery for Active Directory
   This is the English version of my Active Directory recovery...
3. Active-Directory-Daten online wiederherstellen
   Grabsteine beleben mit Werding Das Problem Eben schnell das Windows-Anmeldekonto...

Da (fast) alle meine Demos diesmal als Video vorproduziert waren, werde ich diese in Kürze ebenfalls zur Verfügung stellen.

Hier noch ein paar Links zu den vorgestellten Tools:

• Werding (Skript zum Backup und Restore von Attributwerten, insbesondere im Zusammenhang mit Tombstone Recovery)

[faq-o-matic.net » Active-Directory-Daten online wiederherstellen]
http://www.faq-o-matic.net/2006/11/19/active-directory-daten-online-wiederherstellen/

• ADRestore von Sysinternals

[AdRestore]
http://technet.microsoft.com/en-us/sysinternals/bb963906.aspx

• AD Explorer von Sysinternals

[AD Explorer]
http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx

• Directory Service Comparison Tool von Fredrik Lindström

[Directory Service Comparison Tool 1.3.3.X]
http://lindstrom.nullsession.com/?page_id=11

• ADRecycleBin von Overall Solutions

[ADRecycleBin]
http://overall.ca/index.php?option=com_content&view=article&id=40&Itemid=66

Verwandte Beiträge:

1. ADRestore.NET: Gelöschte AD-Objekte wiederbeleben
   Ein gelöschtes Objekt verschwindet nicht sofort aus Active Directory. Aufgrund...
2. Werding v2 (English version): Online data recovery for Active Directory
   This is the English version of my Active Directory recovery...
3. Fallen und Auswege beim Recovery von Active Directory
   Der Microsoft-Supportmitarbeiter Herbert Mauerer hat einen sehr lesenswerten Artikel zum...

[faq-o-matic.net » AD Snapshots „Deluxe“]
http://www.faq-o-matic.net/2008/10/26/ad-snapshots-deluxe/

Gestern habe ich einen Bug in der aktuellen Fassung 1.3.2.X gefunden, der in speziellen Situationen das Recovery von Objekten verhindert. Der Fehler ist gemeldet, und Fredrik wird sich drum kümmern.

Update: Bereits einen Tag später hat Fredrik das Problem behoben. Die korrigierte Version 1.3.3.X arbeitet wie gewünscht und steht zum Download bereit.

[DSCT 1.3.3.X]
http://lindstrom.nullsession.com/?p=199

Derzeit bereite ich nämlich meine Session “Active Directory Disaster Recovery: Wie mache ich’s richtig” für die ice:2009 in Lingen vor. Dazu nutze ich (wie immer) meine Contoso-Demoumgebung mit 150 realistischen Benutzerkonten. Dort sind die Benutzernamen nach dem Format “Nachname, Vorname” aufgebaut, wie es in vielen deutschsprachigen Umgebungen üblich ist. Dieses Namensschema hat eine Besonderheit: Im AD-Objektnamen (genauer: im Distinguished Name von LDAP-Objekten) ist das Komma ein Trennzeichen für die Elemente des Pfades. Taucht also ein Komma im Namen selbst auf, so muss dies maskiert werden, und zwar mit einem Backslash. Der Name von Ellen Bogen wäre also in diesem Format: “CN=Bogen\, Ellen”.

Bei meiner Vorbereitung wollte ich ein gelöschtes Objekt dieser Art wiederherstellen, doch DSCT meldete einen Fehler. Dieser besagt, dass der Verzeichnisdienst keine Anforderungen entgegennehme. Ich bekam schon einen Schreck und befürchtete, mein Demo-AD (eins von dreien!) sei kaputt. Ist es aber gar nicht.

In Wirklichkeit schlägt hier der Bug in DSCT zu: Es kann Objekte mit Backslash im Namen nicht wiederherstellen. Bei Objekten ohne Backslash klappt es wie gewünscht.

In Kürze wird es sicher eine korrigierte Fassung des hervorragenden Werkzeugs geben.

Verwandte Beiträge:

1. ice:2009: AD-Recovery – die Folien
   Hier die Folien zu meiner Session “Active Directory Disaster Recovery:...
2. Video-Tutorial: Active Directory Object Recovery
   Hinweis: Bei den hier verlinkten Videos handelt es sich (weitgehend)...
3. AD Snapshots „Deluxe“
   Dass man unter Windows Server 2008 mit dem Kommandozeilenprogramm „ntdsutil“...

Warum irrt er?

Zum einen: für mich ist "kein Herstellersupport" ein schlagendes Sachargument, denn ich habe schon zahlreiche Situationen erlebt, in denen man ohne den Hersteller das jeweilige System hätte einstampfen können.

Zum anderen aber – technisch argumentiert: Eine Datenbank wie SQL Server (aber auch alle anderen) arbeitet nach dem "Lazy Writer"-Prinzip. Das bedeutet folgenden Ablauf (schematisch vereinfacht):

1. Eine Applikation fordert eine Änderung von Daten an (UPDATE oder INSERT usw.).
2. SQL Server lädt die betreffenden Datenbankseiten in den Cache (=RAM) bzw. lokalisiert sie dort.
3. SQL Server schreibt die Änderung ins Transaktionsprotokoll.
4. SQL Server ändert die Seiten im Cache (=RAM).
5. SQL Server sendet der Applikation ein Acknowledge über die Änderung.
6. Erst beim nächsten Intervall schreibt SQL Server die Daten in die Datenbankdatei, aber im Regelfall nicht sofort. (Steigert Performance, weil es Random Writes einspart.)

Wenn nun nach Schritt 5 der Strom weg ist – oder man eben einen Snapshot macht -, entsprechen die Daten auf der Platte nicht dem Stand, der an die Applikation berichtet wurde. Nun könnte man argumentieren: Kein Problem, dafür hat man ja das Transaktionsprotokoll. Richtig, hat man auch, und genau dafür ist es da. Das setzt aber voraus, dass das Protokoll auch nutzbar ist – und sich auf exakt demselben Stand (hier also Schritt 3) befindet. Nun liegt das Log aber i.d.R. auf einer anderen LUN als die Datenbank. Ist es also im Falle des "Hot Backups" per Snapshot (oder wie immer) auf demselben Stand? Das wage ich energisch zu bezweifeln.

Selbst in einem normalen Strom-weg-Szenario ohne Snapshot bleibt hier ein Risiko, denn es kann ja sein, dass das Transaktionsprotokoll beschädigt ist. Wenn man hier noch ein Risiko in seinem Backup hat, macht das aus meiner Sicht ein bisschen viel Risiko für einen sensiblen Bereich.

Man kann das auch variieren: Eine Datenbank kann ja auch selbst auf mehrere LUNs verteilt sein – gerade bei großen Datenbanken gibt es mehrere Gründe dafür. Nun betrifft ein Update beispielsweise mehrere Tabellen, die in Datenbankdateien auf mehreren LUNs liegen. Es muss hierbei schon mit schwarzer Magie zugehen, wenn man erwartet, dieses Szenario in einem "Hot Backup" konsistent hinzubekommen. Wir reden ja u.U. von High-Performance-Datenbanken, in der tausende Transaktionen in einer Sekunde verarbeitet werden.

Das muss man aber gar nicht so weit führen. Auch eine Transaktion in einer “ganz normalen” Datenbank, die nicht über mehrere LUNs verteilt ist, kann Datenbankseiten auf ganz unterschiedlichen Plattenbereichen betreffen. Natürlich müssen diese Änderungen alle gemeinsam geschrieben werden (oder eben gar nicht). Ein “Hot Backup” wie ein Snapshot kann aber nicht wissen, wann eine Transaktion abgeschlossen ist und “fotografiert” einfach mitten rein. Hier kann ein weiteres Problem auftreten: Eine Datenbankseite wird gar nicht vollständig geschrieben (“Torn Page”). Ein solches Problem wird u.U. nicht beim anschließenden Durchlauf der Transaktionsprotokolle beim Neustart der Datenbank behoben und bleibt unentdeckt. Je nach Konfiguration der Datenbank hat man also das Risiko unbrauchbarer Daten – oder die Datenbank hält an, weil sie das Problem bemerkt hat (“Torn Page Detection”) und fordert zum Restore aus einem Backup auf. Dumm, wenn das Restore gerade der Grund für das Problem war.

Auch der manchmal vorgeschlagene “Ausweg”, Datenbank- und Transaktionsprotokolldateien auf dieselbe LUN zu legen, um mit einem einzigen Snapshot arbeiten zu können, ist also kein echter Ausweg. Zumal man dies bei belasteten Datenbanken schon deshalb nicht machen wird, weil ein Transaktionsprotokoll auch mal plötzlich sehr stark anwachsen kann und auf einer separaten LUN besser aufgehoben ist.

Und das Argument mit "unwahrscheinlich" wird schon von der Praxis widerlegt, denn im Support gibt es ständig Anwenderprobleme, die auf Inkonsistenzen durch falsche Datenbanksicherungen zurückzuführen sind. Das hat z.B. überhaupt nichts mit der Dauer zu tun, die ein Snapshot zum Erzeugen braucht, sondern liegt einfach in der Art, wie relationale Datenbanken ihre Daten ablegen.

Schließlich bleibt das Nutzenargument: SQL Server hat etwa mit der VSS-Schnittstelle eine eingebaute (und supportete) Möglichkeit, für Backupzwecke eine Konsistenz zu erzeugen. Warum darauf verzichten und ein noch so kleines Risiko eingehen?

Verwandte Beiträge:

1. MS SQL 2005: Transaction Log von der Datenbank trennen
   Mit dem "MS SQL Server Management Studio" ist es nicht...
2. SCVMM: VM aus der Datenbank entfernen
   In einer speziellen Situation ergab sich die Anforderung, eine virtuelle...
3. Warum Images nicht als Datensicherung taugen
   Images sind sehr beliebt. Die Technik, eine ganze Festplatte oder...