Active Directory - Backup und Restore, Teil 1
AD-Sicherung mit Bordmitteln
Die Sicherung des Active Directory muss kein Geheimnis pompöser Backup-Management-Suiten sein. Dass es auf Wunsch auch kostenfrei und übersichtlich geht, zeigt eine kleine Serie in der LANline. Teil 1 befasst sich mit wichtigen Grundlagen und der Sicherung des Systemstates.
In Zeiten verteilter Systeme und komplexer IT-Landschaften ist die Sicherung und
Wiederherstellung von Daten nach wie vor ein brisantes Thema. Heutzutage müssen sich
IT-Verantwortliche mit Backup-Strategien und Desaster-Recovery-Szenarien auseinandersetzen, um für
alle Fälle gewappnet zu sein. Die Zeiten, wo es ausschließlich um Backup und Restore einzelner
Dateien ging, sind lange vorbei. Mittlerweile verlangt die Implementierung eines soliden
Datensicherungskonzepts hohen technischen Sachverstand. Herausfinden und sagen zu können, ob man im
Schadensfall gewappnet ist, ist nicht immer einfach.
Eines dieser kritischen und komplexen Systeme ist der Verzeichnisdienst Active Directory (AD),
der in vielen Unternehmen zur Autorisierung und Authentifizierung von Benutzern eingesetzt wird.
Was ist hier in Bezug auf die Datensicherung zu beachten? Welche Vorkehrungen lassen
Administratoren ruhig schlafen? Dieser Artikel gibt Antwort darauf und zeigt Ideen für den
Praxisalltag, die allesamt auf Bordmitteln basieren.
Datenspeicherung und Löschen im Active Directory
Je nach IT-Infrastruktur besteht eine Active-Directory-Umgebung aus zwei oder mehr
Domänen-Controllern (DC). Ein AD ließe sich auch mit einem DC betreiben, aus Gründen der
Ausfallsicherheit ist allerdings nur ein redundantes Zusammenspiel mit mehr als zweien wirklich
sinnvoll. Nach oben gibt es übrigens keine Grenzen. Das Design ist frei, wenn auch von einigen
Regeln abhängig, die für das Wiederherstellen von Informationen an dieser Stelle nicht von
Bedeutung sind. Active-Directory-Umgebungen mit 50 oder mehr DCs, in weit verteiltem und
länderübergreifendem Umfeld, sind heute keine Seltenheit mehr. Die genaue Anzahl ergibt sich aus
den Anforderungen der Standorte, der Verbindungsbandbreite und natürlich der Anzahl der Benutzer,
die sich an dem AD authentifizieren. Replikation sorgt für eine Verteilung der Datenbank auf alle
DCs und dafür, dass jeder DC über den aktuellen Stand des Verzeichnisses verfügt.
Jeder Anwender, der samt seinem Computerkonto Mitglied in einer Active-Directory-Domäne ist,
kommuniziert nach dem Anmelden mit genau einem DC in seiner Domäne. Die Berechnung, welcher DC
hierfür in Frage kommt, erfolgt auf Basis von Standorttopologie und Subnetz.
Änderungen imActive-Directory-Bereich, wenn beispielsweise ein Administrator eines der
Benutzerkonten bearbeitet oder wenn ein Anwender in Eigenregie sein Passwort ändert, nimmt der für
ihn zuständige DC entgegen. Hierbei wird die USN (Update Sequence Number) für das geänderte Objekt
erhöht, was die Notwendigkeit einer Replikation gegenüber anderen DCs kennzeichnet. Auf diese Art
lassen sich Änderungskonflikte vermeiden und die Integrität des Verzeichnisdienstes jederzeit
sicherstellen.
Die Arbeit mit "Tombstone"-Objekten
Das Gleiche gilt auch für das Löschen, nur dass dies in zwei Schritten erfolgt. Am Beispiel
eines Benutzerkontos wird dieses vorab zum Löschen zu einem späteren Zeitpunkt markiert. Man
spricht hier von einem "Tombstone". Ein Objekt wird zum Tombstone-Objekt indem das
IsDeleted-Attribut den Wert "True" erhält und einen Großteil aller Attribute verliert. Zusätzlich
wird es umbenannt in \0ADEL: und landet in dem versteckten System-Container "Deleted Objects" der
Partition, der das Objekt entstammt. Auch hier wird die USN erhöht und der Tombstone letztendlich
repliziert. So gerupft, verbleibt das gelöschte Konto dann für einen Zeitraum von 60 Tagen in der
Datenbank, der so genannten "Tombstone Lifetime". Ab Windows Server 2003 SP1 beträgt der Zeitraum
180 Tage – allerdings nur, wenn die Domäne mit SP1 installiert wurde. Nach diesem Zeitraum wird im
zweiten Schritt der Tombstone durch den Aufräumprozess (Garbage Collection) endgültig entfernt.
Während der Tombstone Lifetime, die übrigens für den gesamten Forest gilt, lassen sich gelöschte
Konten reanimieren, vorausgesetzt man ist im Besitz eines Systemstate Backup oder hat die richtigen
Tools zur Hand, wie es weiter unten beschrieben wird.
Die tägliche Pflicht - Sicherung des Systemstates auf einem DC
Jedes Backup-Programm, das von sich behauptet, Windows-kompatibel zu sein, sollte den
Systemstate sichern können. Mit der Sicherung des Systemstates von einem DC hat man automatisch
eine Sicherung des Active Directories. Da im Grunde genommen immer alle Server gesichert werden,
auch die DCs, kann daraufhin eigentlich nichts mehr passieren. Richtig: eigentlich. Es gibt Gründe,
die dafür sprechen, auf dem DC neben der üblichen Datensicherung eine zusätzliche Sicherung
durchzuführen und den Systemstate in Dateiform vorzuhalten: Zum Einen ist dadurch eine schnelle
Wiederherstellung gewährleistet, da eine lokale Sicherung unabhängig von extern gelagerten Medien
ist.
Unabhängigkeit von der eingesetzten Backup-Lösung
Ein weiterer Grund ist die Unabhängigkeit von der eingesetzten Backup-Lösung. Die weiter unten
vorgestellte Restore-Lösung basiert auf Bordmitteln, sodass die Installation einer spezifischen
Sicherungssoftware auf dem DC überflüssig wird. Man nehme das in Windows integrierte Backup Utility
(ntback up.exe) und den Task Scheduler, und schon lassen sich nachts Sicherungen des Systemstates
auf einen lokalen Datenträger des DCs durchführen. Das Backup Utility ist nämlich nicht nur über
die grafische Oberfläche zu bedienen, sondern lässt sich auch von der Kommandozeile aus aufrufen
und bietet damit alles für den Scheduler notwendige. Folgender Befehl erstellt eine Sicherung des
Systemstates von der Kommandozeile:
ntbackup backup systemstate /j "Name der Sicherung" /F C:\Backupfolder\ Backupfile.bkf /l:f
Der Parameter "/J" kennzeichnet den Namen der Sicherung (Jobname). Hinter "/F" folgen Pfad- und
Dateiname, und "/L:F" initiiert eine Sicherung mit umfangreicher Protokolldatei (Logging=Full).
Nimmt man das Kommando, eingebettet in ein Batchfile mit etwas Funktionalität, in Verbindung mit
dem Task Scheduler, lassen sich kleine lokale Backup-Sets realisieren, wie zum Beispiel eine
Sicherung an jedem Werktag, mit wöchentlicher Aktualisierung.
Die Paranoia pflegen ohne hohe Kosten
Zugegebenermaßen ist es ein wenig paranoid, auf jedem DC eine zusätzliche Sicherung vorzuhalten - und das Ganze auch noch über den Zeitraum von einer Woche. Auf der anderen Seite aber kostet es nicht viel Aufwand, und bei der Sicherung eines derart wichtigen und zentralen Services kann ein zweites Sicherungsstandbein nicht schaden. Es ist aber auch wichtig zu wissen, dass das beschriebene Verfahren ein etabliertes Backup-Verfahren keinesfalls ersetzen kann, da bei einem Brand im Serverraum oder bei einem Defekt einer Festplatte ohne Redundanz alle Sicherungen verloren sind. Bei der Sicherung des Systemstates ist nicht zu vergessen, dass dieses hardwarenahe Informationen enthält und bei einem Restore, wenn die Serverhardware eine andere ist, Probleme zu erwarten sind.
Achtgeben bei der Sicherung
Gleichgültig, wie die Sicherung des Systemstates auf einem DC erfolgt – auf Festplatte, auf
Band, mit Bordmitteln oder mit der Backup-Software eines Drittherstellers –: Beim Archivieren ist
unbedingt darauf zu achten, das die Sicherungen nicht älter sind als der bereits erwähnte
Tombstone-Zeitraum, da eine Wiederherstellung über diesen Zeitraum hinaus dann ausgeschlossen
ist.
Im Übrigen muss ein Domänen-Controller bei der Sicherung immer online sein. Eine Sicherung
beispielsweise über ein Imaging-Verfahren ist deshalb eher wenig sinnvoll, da dies an den logischen
Mechanismen wie etwa Replikation und Handhabung von USNs im Active Directory vorbeigeht, und mit
hoher Wahrscheinlichkeit Inkonsistenzen in der Datenbank zur Folge hätte [1].
Lesen Sie mehr zum Thema
