Grundfunktion

Altaro Hyper-V Backup nutzt die VSS-Schnittstelle (Volume Shadowcopy Services) von Hyper-V, um konsistente Datensicherungen virtueller Maschinen zu erzeugen. Das ist nicht zu verwechseln mit der Snapshot-Funktion von Hyper-V – die Software fertigt keine solchen Snapshots an, weil diese zu unerwünschten Nebeneffekten führen können. Die VSS-Integration sorgt vielmehr dafür, dass Hyper-V eine bestimmte virtuelle Maschine kurz in einen konsistenten Zustand versetzt, damit die Sicherungssoftware diesen unbesorgt sichern kann. Mit unterstützten Betriebssystemen geht dies sogar noch einen Schritt weiter, denn die Integration Services von Hyper-V rufen ihrerseits innerhalb der VM den VSS auf, damit dieser alle registrierten Anwendungen (z.B. SQL Server oder Exchange) über das Backup informiert. Im Effekt kann man davon ausgehen, dass auch die wichtigsten Serverapplikationen im Backup in einem konsistenten Zustande sich befinden.

Weitere Funktionen

Die Fähigkeiten der Software sind sehr interessant. Hier eine kurze Liste:

• Unterstützt Hyper-V-Cluster einschließlich CSV (Cluster Shared Volumes)
• Unterstützt auch Core-Installationen und den kostenlosen Hyper-V Server 2008 R2
• Wiederherstellung einer VM auf demselben oder einem anderen Host
• Wiederherstellung einer VM als Klon unter anderem Namen
• Wiederherstellung einzelner Dateien aus einer VM
• Eingebauter Job- und Zeitplaner
• Automatisierte Testfunktion für den Restore-Vorgang
• Versionierung – bestimmte Zustände einer VM sind gezielt wiederherstellbar
• VM-Snapshots können ins Backup integriert werden
• Die wichtigste Funktion ist “Reverse Delta”: Bei wiederholten Backups kann man nur die Veränderungen zum vorherigen Stand sichern, was Zeit und Platz spart. Dabei ist die jüngste Sicherung stets vollständig, was die Sicherheit erhöht und den Zeitbedarf für den wahrscheinlichsten Restore-Vorgang (letzter Stand) reduziert

Kurzer Praxis-Überblick

Hier ein paar Eindrücke des Produkts im produktiven Umgang.

Grundeinstellungen

Dashboard: Im Startbildschirm gibt die Software einen Überblick über Backup-Vorgänge und den Platz auf dem Backup-Medium. Derzeit arbeitet Altaro Hyper-V Backup ausschließlich mit Festplatten als Medium. Eine evtl. gewünschte Übertragung der gesicherten Daten auf Band müsste man separat über eine andere Sicherungssoftware einrichten.

Konfiguration der Sicherungsvorgänge: Die Software erlaubt eine gezielte Auswahl von VMs, die sie sichern soll. Dabei kann man mit unterschiedlichen Zeitplänen und Einstellungen arbeiten.

Auswahl der zu sichernden VMs

Auswahl des Sicherungsmediums: Man kann zwei getrennte Laufwerke auswählen und optional einen Abgleich zwischen beiden einrichten.

Benachrichtigungen können per Eventlog und/oder per Mail an den Administrator gehen.

Sicherung

Die Optionen der Sicherung lassen sich getrennt für jede VM einstellen. Das betrifft nicht nur den Zeitplan, sondern auch die “Reverse Delta”-Vorgaben und die Versionierung.

Wiederherstellung

Auch für die Wiederherstellung lassen sich einige Einstellungen vorgeben. Das betrifft hier die VM-Version und die Frage, ob das Restore auf dem ursprünglichen oder einem anderen Hyper-V-Host erfolgen soll.

Bei der Wiederherstellung auf einen anderen Host wird dieser über das Netzwerk angesprochen.

Wiederherstellung einzelner Dateien

Beim Recovery einzelner Dateien aus einer VM-Sicherung bedient sich das Produkt eines Tricks. Es stellt die VM (in der gewünschten Version) temporär als VHD-Datei in einem Dateipfad wieder her und bindet diese VHD-Datei dann über die Windows-Bordmittel als Laufwerk ein. Dadurch kann man dann bequem im Explorer die benötigten Dateien auswählen und an den Zielort kopieren.

Auswahl der VM-Version

Die temporäre VHD ist erzeugt und kann nun ins Dateisystem eingehängt werden (mount).

Die VHD-Dateien der VM sind einzeln als Laufwerke ins Dateisystem des steuernden Rechners eingebunden worden (hier: F: und H:). Im Explorer besteht einfacher Zugriff auf das Dateisystem der VM. Die wiederhergestellte VM selbst läuft zu diesem Zeitpunkt nicht, d.h. den Vorgang kann man ausführen, ohne die Produktionsumgebung zu beeinflussen.

Wiederherstellungs-Tests

Das Produkt bietet auch eine Unterstützung für regelmäßige Notfallübungen. Dabei hat man die Auswahl aus zwei Methoden: Entweder verschickt das System nur eine Aufforderung zum Test – oder es führt gleich automarisch ein Test-Recovery aus.

Verwandte Beiträge:

1. Betatest: Altaro Hyper-V Backup
   Der Software-Hersteller Altaro, bekannt für sein Client-Backuptool “Oops!Backup”, wird in...
2. Hyper-V-Backup mit Altaro
   Vor einigen Wochen haben wir über die Betaphase einer Backuplösung...
3. Altaro Hyper-V Backup (Beta)
   Der Software-Hersteller Altaro, bekannt durch sein Client-Backup- und Versionierungsprogramm “Oops!Backup”,...

Der Hersteller positioniert seine Software primär für kleinere und mittelständische Unternehmen, doch auch in größeren Umgebungen kann man das Microsoft Hyper-V Backup damit ausführen.

In Kürze werden wir einen etwas ausführlicheren Blick auf das Produkt werfen – einstweilen verweisen wir auf unseren Eindruck aus der Alpha-Phase:

[faq-o-matic.net » Altaro Hyper-V Backup (Beta)]
http://www.faq-o-matic.net/2011/05/09/altaro-hyper-v-backup-alpha/

Als Bonbon für unsere Leserinnen und Leser werden wir außerdem in den kommenden Wochen eine Lizenz für die “Unlimited Edition” der Software verlosen.

Verwandte Beiträge:

1. Betatest: Altaro Hyper-V Backup
   Der Software-Hersteller Altaro, bekannt für sein Client-Backuptool “Oops!Backup”, wird in...
2. Altaro Hyper-V Backup (Beta)
   Der Software-Hersteller Altaro, bekannt durch sein Client-Backup- und Versionierungsprogramm “Oops!Backup”,...
3. Altaro Hyper-V Backup: Überblick und Verlosung
   Vor einiger Zeit haben wir bereits das Produkt Altaro Hyper-V...

Die folgende Skriptlösung zeigt, wie man mit robocopy ein Datensicherungssystem aufbauen kann, das täglich die Änderungen eines Datenbestandes in einen Tages-Ordner kopiert. Hierbei erzeugt das Skript für jeden Wochentag (Montag, Dienstag usw.) einen Ordner und legt dort die gesamten Daten der Quelle ab. Als Ergebnis erhält man ein tagesaktuelles, versioniertes Backup seiner Daten, das tageweise bis zu einer Woche zurückreicht. Die tatsächliche Dateiauswahl kann man über die Parameter von robocopy anpassen.

Zunächst muss das Skript ein Problem lösen: In der Standard-Shell gibt es keine zuverlässige Möglichkeit, den Wochentag zu bestimmen. Daher nutzt die Lösung ein separates VBS-Skript, das diese Aufgabe erledigt. Es gibt  beim Aufruf den Namen des Wochentages zurück. Über einen FOR-Trick liest das Batch den Tag ein und legt ihn in der Variablen %Day% ab.

Den Rest erledigt dann der robocopy-Aufruf. In der hier vorliegenden Variante nutzt er die Mirror-Funktion, d.h. er erzeugt eine Kopie der Quelldaten mitsamt ihrer Ordnerstruktur im Zielordner. Dabei muss robocopy nur die Daten kopieren, die nicht bereits am Ziel liegen – ab der zweiten Woche kopiert es also nur das, was sich gegenüber der vorherigen Woche geändert hat. Gelöschte Quelldateien entfernt es auch am Ziel. Auf diese Weise lassen sich Änderungen bis zu sechs Tage lang in Tagesschritten manuell wiederherstellen.

Skript 1: Das Backup-Batch (Wochenbackup.bat)

@echo off
REM Umgebung festlegen
SET Source="C:\Daten\Wichtig"
SET Target="D:\Backups"

REM In Skript-Ordner wechseln
CD %0\..\

REM Ordner fuer Wochentag identifizieren und ggf. anlegen
FOR /F "usebackq" %%I IN (`cscript Wochentag.vbs`) DO SET Day=%%I
IF NOT EXIST %Target%\%Day% md %Target%\%Day%

REM Kopierjob 1
ROBOCOPY %Source% %Target%\%Day% /Z /MIR /MT /R:3

Skript 2: Bestimmen des Wochentags per VBS (Wochentag.vbs)

Select Case WeekDay(Now)
	Case 1 strTag = "Sonntag"
	Case 2 strTag = "Montag"
	Case 3 strTag = "Dienstag"
	Case 4 strTag = "Mittwoch"
	Case 5 strTag = "Donnerstag"
	Case 6 strTag = "Freitag"
	Case 7 strTag = "Samstag"
End Select

WScript.Echo strTag

Und hier der Download der Skripte:

Verwandte Beiträge:

1. Werding v2 (English version): Online data recovery for Active Directory
   This is the English version of my Active Directory recovery...

Update: Wie wir gerade vom Hersteller hören, ist die Beta-Phase nun gestartet worden. Näheres unter:

[Altaro Hyper-V Backup Beta]
http://www.altaro.com/hyper-v-backup/

Hyper-V Backup arbeitet mit VSS-Snapshots. Es integriert sich mit der VSS-Schnittstelle des Hyper-V-Hosts, um die virtuellen Maschinen für das Backup in einen konsistenten Zustand zu bringen. Diese Standardfunktion des Betriebssystems weist die VMs an, ihre Schreibzugriffe kurz einzustellen, damit Windows einen Snapshot des beteiligten Datenträgers erzeugen kann. Diesen Snapshot sichert die Software dann. Dabei arbeitet Hyper-V Backup mit plattenbasierten Sicherungen, wobei es parallel zwei Sicherungslaufwerke einbinden kann, auf die es optional abwechselnd schreibt.

Auf Grundlage der Backups kann man eine gesicherte VM wiederherstellen, um sie nahtlos weiter zu betreiben. Alternativ ist es möglich, die VM an einem anderen Speicherort zu restaurieren, um auf dieser Grundlage eine Kopie der virtuellen Maschine zu erzeugen. In diesem Fall bietet die Software an, die VM offline zu starten, damit der Administrator ihr eine neue Netzwerkkonfiguration geben kann.

Der Clou der Backupsoftware besteht in der “Reverse Delta”-Technik, die Altaro auch in seinen anderen Produkten einsetzt. Dieser Ansatz speichert immer nur die Veränderungen gegenüber dem letzten Backup, allerdings in “umgekehrter Reihenfolge”: Die jeweils letzte Sicherung ist immer die vollständige Datei. Die älteren Versionen werden dann so umgearbeitet, dass in ihnen nur die Abweichungen zum jeweils nachfolgenden Stand abgelegt sind. Das ist ein grundlegender Unterschied zu herkömmlichen “inkrementellen” Sicherungen, denn diese legen einmal eine Vollsicherung ab und fügen danach die Änderungen neuer Fassungen hinzu. Auf diese Weise ist bei der traditionellen Technik immer nur die älteste Fassung vollständig, während der aktuelle Stand aus mehreren Teilen zusammengefügt wird. Da Altaro den umgekehrten Weg geht, ist das Restore des jeweils aktuellsten Standes am schnellsten und mit dem geringsten Risiko behaftet.

Hier einige Eindrücke der Alpha-Version.

Laufendes Backup: Die Software sichert eine einzelne VM. Natürlich kann sie auch mehrere virtuelle Maschinen sichern, aber der Einfachheit halber ist es hier nur eine. Das Sicherungsziel ist ein Ordner auf einer Festplatte. Hier kann man externe Platten, interne Datenträger oder auch Netzwerk-Speicherpfade angeben.

Snapshot in der VM: Innerhalb der VM, die gesichert wird, kann man den VSS-Dienst in Aktion sehen, der für den konsistenten Snapshot sorgt. Natürlich läuft die VM während dieser Aktion unbeeindruckt weiter, nur im exakten Moment des Snapshots setzt sie ihre Schreibaktivitäten kurz aus.

In der Konsole der Software kann die Administratorin steuern, wie VSS den Snapshot erzeugt. Dabei gibt es die Auswahl “VSS Full” und “VSS Copy”. Die “Full”-Option weist dabei den VSS-Dienst an, die Backup-Historie der VM zu erweitern und die Backup-Schnittstelle der beteiligten Programme zu informieren. Dadurch würde dann etwa eine Datenbank ihre Log-Dateien aufräumen. In der zweiten Variante “Copy” erzeugt VSS nur einen weiteren Snapshot, ohne diesen mit den Applikationen zu integrieren. Diese Option ist dann sinnvoll, wenn zusätzlich zu Altaro Hyper-V Backup eine weitere Sicherungssoftware eingesetzt wird, die die Ansprache der Applikationen übernehmen soll. In solch einem Szenario stellt Hyper-V Backup nur die zweite Backup-Ebene dar und erzeugt Backup-Kopien, ohne das Sicherungsverfahren der anderen Anwendung zu beeinträchtigen.

Snapshot beendet: Auch das Ende des Snapshot-Vorgangs findet sich im Eventlog der VM.

Dateistruktur: Das Programm legt seine Daten in einer eigenen Dateistruktur ab. Der Ordner “Latest” enthält immer die letzte, vollständige Sicherung. Ältere Varianten sind als “Reverse Delta” in separaten Ordnern abgelegt.

Restore-Auswahl: Sobald es mehr als ein Backup einer VM gibt, kann man beim Restore auswählen, welches man wiederherstellen möchte. Zudem kann die Administratorin angeben, ob sie eine fehlerhafte VM ersetzen oder das Restore als Basis für einen “Klon” nutzen möchte.

Wiederherstellung läuft: Die Konsole gibt Auskunft über den Vorgang, der aber im Hintergrund abläuft und die Arbeit des Hosts nicht weiter beeinträchtigt.

Historie: Die Reporting-Funktion der Software ist in der Alpha-Version noch sehr eingeschränkt. Hier werden sich künftig wahrscheinlich weitere nützliche Berichte finden.

Verwandte Beiträge:

1. Hyper-V-Backup mit Altaro
   Vor einigen Wochen haben wir über die Betaphase einer Backuplösung...
2. Betatest: Altaro Hyper-V Backup
   Der Software-Hersteller Altaro, bekannt für sein Client-Backuptool “Oops!Backup”, wird in...
3. Altaro Hyper-V Backup: Überblick und Verlosung
   Vor einiger Zeit haben wir bereits das Produkt Altaro Hyper-V...

Aus der Feature-Liste:

• Hot Backups – Back up running VMs without stopping them.
• Fully Hyper-V Aware – Altaro Hyper-V Backup does all the complex config connections and allows you to backup any instance in 5 clicks or less.
• Agent Less – Installs on Hyper-V Host without installing anything within the VM itself.
• Flexible & Fully Featured – Backup or Restore Individual VMs without having to restore an entire volume.
• Restore individual or a group of VMs to a different Hyper-V host.
• Restore from multiple points in time rather than 'the most recent backup'.
• ReverseDelta Incremental Backup Technology for Super Efficiency.
• Ability to have different backup schedules for different VMs.
• Can restore VMs to the same Hyper-V Host but with a different name – i.e. does not overwrite existing VM – Cloning.
• Backup crash consistent Linux VMs without shutting down the machine.

Nähere Informationen und die Bewerbung für die Beta gibt es hier:

[Altaro Hyper-V Backup Beta]
http://www.altaro.com/hyper-v-backup/

Verwandte Beiträge:

1. Hyper-V-Backup mit Altaro
   Vor einigen Wochen haben wir über die Betaphase einer Backuplösung...
2. Altaro Hyper-V Backup (Beta)
   Der Software-Hersteller Altaro, bekannt durch sein Client-Backup- und Versionierungsprogramm “Oops!Backup”,...
3. Altaro Hyper-V Backup: Überblick und Verlosung
   Vor einiger Zeit haben wir bereits das Produkt Altaro Hyper-V...

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...

Die Datenablage ist eine der wichtigsten Funktionen eines Datenbankservers: Nicht nur sollen die Daten zuverlässig auf der Festplatte landen, sondern das soll auch noch möglichst schnell geschehen. Und schließlich sollen die Daten meist nicht nur auf der Platte stehen, sondern in regelmäßigen Abständen zur Datensicherung auch auf ein Band oder ein anderes externes Medium kopiert werden.

Microsofts SQL Server setzt hierfür einige Mechanismen ein, die sich schon seit mehr als einem Dutzend Jahren nicht prinzipiell verändert haben. Trotzdem sind diese Grundlagen den meisten Admins weitgehend unbekannt. Dieser Artikel gibt ein wenig Überblick.

Das Protokoll-Prinzip

Mit vielen anderen Datenbanksystemen teilt sich SQL Server das Prinzip des “Write-ahead logging”, um die Konsistenz seiner Transaktionen auch über mögliche Systemausfälle hinweg zu gewährleisten. Hinter diesem hochtrabenden Namen verbirgt sich eine recht einfache Idee: SQL Server bestätigt die Annahme von Daten von einem Client erst dann, wenn er sie sicher auf die Festplatte geschrieben hat. Dabei bedient er sich allerdings noch eines – ebenfalls weit verbreiteten – Tricks: Der Server schreibt die Daten nicht sofort in die Datenbank-Datei. Solche Dateien können nämlich sehr groß werden, und sie sind intern in einer Weise organisiert, die insbesondere effiziente Lese- und Suchvorgänge unterstützt. Im Effekt muss der Datenbankserver daher die Daten innerhalb einer möglicherweise riesigen Datei an einer ganz bestimmten Stelle speichern, die er zunächst identifizieren muss, und gleich darauf muss er an eine ganz andere Stelle schreiben, um das nächste Datenpaket loszuwerden. Und das alles nur, um Daten zu speichern, die im nächsten Moment vielleicht schon wieder geändert sind.

Aus diesem Grund versuchen die meisten Datenbanksysteme, den Schreibzugriff auf die Datenbank-Datei so selten wie möglich auszuführen. Sie fassen mehrere einzelne Schreibvorgänge zu einem größeren zusammen, wobei sich oft auch der Effekt ergibt, dass Daten, die bereits von anderen Daten ersetzt sind, nur einmal und nicht mehrfach geschrieben werden müssen. Dieses Prinzip nennt man auch “Lazy Writer”.

Damit die Daten nun also einerseits sofort nicht-flüchtig auf der Platte stehen, andererseits aber der Zugriff auf die komplexe Datenbankdatei so selten wie möglich erfolgt, haben Datenbanken dieser Art eine zweite Datei, nämlich die Log-Datei (auch: Transaktionsprotokoll-Datei). Dort protokolliert der Server jede einzelne Transaktion ohne weitere Rücksicht auf spätere Lesevorgänge. Diese Log-Datei lässt sich also einfach sequenziell beschreiben: Alle Transaktionen protokolliert das System vollständig, indem es sie – vereinfacht gesagt – am Ende der Log-Datei anfügt.

Tatsächlich sind es also zwei Dateien bzw. zwei Sätze von Dateien, die eine derartige Datenbank zur Speicherung benötigt. Dabei wird deutlich, dass die Log-Datei ganz entscheidend über die Geschwindigkeit der Transaktionsverarbeitung (also aller Änderungen an der Datenbank) entscheidet, denn jede Änderung wird erst in der Datei protokolliert und dann bestätigt. Hochdynamische Datenbanken brauchen daher für die Log-Dateien ein Plattensystem, das eine hohe Verarbeitungsgeschwindigkeit für sequenzielle Schreibvorgänge ermöglicht. Es ist durchaus keine Seltenheit, dass man dafür Stripe-Sets aus kleinen, schnellen Platten einsetzt (gern gespiegelt – also z.B. RAID 10). Das ist allerdings längst nicht für jede Datenbank nötig, sondern nur für solche, die richtig hohe Schreibleistung brauchen. Die meisten Datenbanken für “übliche” Anwendungen (auch ERP-Systeme im Mittelstand) werden mit weniger I/O-Leistung auskommen und daher auf “normalen” Plattensystemen zufriedenstellend arbeiten.

Wenn man das Logging richtig behandelt (mehr dazu siehe unten), werden die Log-Dateien für die meisten Datenbanken im Vergleich zur vollständigen Datenbankgröße eher überschaubar sein. Es kann aber durchaus vorkommen, dass die Protokolldateien plötzlich stark anwachsen, und zwar dann, wenn es viele oder sehr große Transaktionen in kurzer Zeit gibt. Eine typische Situation dieser Art sind umfangreiche Import-Vorgänge in die Datenbank – jeder importierte Datensatz wird natürlich einzeln protokolliert.

Auf jeden Fall aber sind die Transaktionsprotokolle produktionskritisch: Ohne Protokoll keine Veränderung in der Datenbank. Als Hintergrund halte man sich den Sinn des Transaktionsprotokolls vor Augen: Es ist der ausschlaggebende Mechanismus, der gewährleistet, dass man sich auf die Datenbank verlassen kann. In einer komplexen Transaktion, die aus vielen einzelnen, aber zusammenhängenden Änderungen besteht, muss die Applikation gewährleisten, dass der Vorgang entweder vollständig oder aber gar nicht stattfindet. Man stelle sich vor, bei einer Bank-Überweisung, die aus den beiden Schritten “Abbuchen von 100.000 Euro von Konto X und Gutschreiben derselben Summe auf Konto Y” besteht, findet nur der erste Schritt statt, der zweite aber nicht. Die Bank freut sich – aber gleich zwei Kunden haben Grund zur Klage. Das Datenbanksystem muss also sicherstellen, dass eine unterbrochene Transaktion vollständig widerrufen wird, damit sie sauber neu ausgeführt werden kann. Umgekehrt muss eine Transaktion, die das System bestätigt hat, auch zuverlässig in der Datenbank vermerkt sein.

Daher kann bei einem transaktionsgeschützten System kein Vorgang ohne Protokoll stattfinden. Steht das Protokoll nicht zur Verfügung, ist der Server also gezwungen, die ganze Datenbank offline zu nehmen. Der korrekte Umgang mit den Log-Dateien ist also eine Kernaufgabe des Datenbank-Operating.

Wie SQL Server Änderungen verarbeitet

Hier noch einmal eine kurze (und vereinfachte) Zusammenfassung, wie SQL Server Änderungen an einer Datenbank verarbeitet.

1. Ein Client fordert eine bestimmte Änderung von Daten an.
2. SQL Server prüft, ob sich die betroffenen Daten (genauer: Die Speicherbereiche der Datenbank, auf denen sich die Daten befinden – auch als “Datenbank-Seiten” bezeichnet) bereits im Arbeitsspeicher befinden. Falls nicht, lädt er die Seiten ins RAM.
3. SQL Server protokolliert die Änderungen im Transaktionsprotokoll.
4. SQL ändert die Datenbank-Seiten im Arbeitsspeicher.
5. SQL Server gibt dem Client die Bestätigung über die Transaktion.
6. Beim nächsten sog. Checkpoint-Vorgang schreibt SQL Server die geänderten Datenbank-Seiten aus dem Arbeitsspeicher in die Datenbankdatei auf der Festplatte. Den Checkpoint vermerkt das System im Transaktionsprotokoll: Alle Transaktionen vor dem Checkpoint sind in der Datenbank fixiert, die betreffenden Transaktionen sind im Protokoll also nicht mehr aktiv.

Was SQL Server nun als nächstes mit dem Transaktionsprotokoll tut, hängt davon ab, wie die Datenbank konfiguriert ist. Entscheidend ist dabei das “Recovery Model” (Wiederherstellungsmodell), das als Datenbankoption durch den Administrator konfigurierbar ist. Steht es auf “Vollständig” (Full), so lässt SQL Server alle inaktiven Transaktionen im Transaktionsprotokoll stehen und schreibt neue Transaktionen ans Ende der Protokolldatei. Erst wenn der Admin eine Protokollsicherung (Log Backup) ausführt, gibt SQL Server die “alten”, inaktiven Transaktionen frei, und das System kann den Platz innerhalb der Datei wieder nutzen. Der Vorteil: Auf diese Weise lassen sich die Transaktionsprotokolle auch zur Wiederherstellung nach einem Datenverlust einsetzen, denn sie enthalten ja sämtliche Änderungen am Datenbestand (siehe unten). Der Nachteil: Sorgt man nicht für ein regelmäßiges Backup der Logs, so wachsen diese endlos an, bis die Platte voll ist. Als Folge bleibt dann die ganze Datenbank stehen – denn ohne Protokoll kein Zugriff.

Im Modell “Einfach” (Simple) hingegen gibt SQL Server den Platz innerhalb der Datei bei jedem Checkpoint wieder frei. Dadurch kann die Datei nicht unkontrolliert anwachsen und stellt im Normalfall kein Risiko für die Plattenbelegung und den Online-Status der Datenbank dar. Allerdings lassen sich die Transaktionsprotokolle in diesem Fall auch nicht für das Restore von Daten einsetzen, weil sie ja nicht lückenlos vorliegen.

“Recovery” und “Restore” – hier nicht dasselbe!

Eine Besonderheit bringt der SQL Server mit: Die Begriffe “Recovery” und “Restore”, die man sonst oft synonym verwendet, bezeichnen hier völlig unterschiedliche Dinge. Man sollte sie auseinanderhalten, wenn man verstehen möchte, was SQL Server in welcher Situation tut. Ungünstigerweise übersetzt die meiste deutschsprachige Dokumentation beide Begriffe mit demselben Wort “Wiederherstellung” …

Recovery: Automatisch beim Systemstart

Der “Recovery”-Vorgang läuft immer automatisch beim Systemstart ab bzw. wenn SQL Server eine Datenbank online stellen soll. In diesem Moment muss das System sicherstellen, dass die Datenbank sich in einem konsistenten Zustand befindet. Dazu überprüft der Server das Transaktionsprotokoll der Datenbank, ob sich dort nach dem letzten Checkpoint noch Transaktionen befinden. Falls ja, schreibt das System die abgeschlossenen Vorgänge (“committed transactions”) in die Datenbank. Dies nennt sich “rollforward”. Die nicht abgeschlossenen Vorgänge, die also z.B. durch einen Ausfall des Servers unterbrochen wurden (“uncommitted transactions”) entfernt der Server aus dem Protokoll. Dies nennt man “rollback”.

Erst nach dem Abschluss dieses Prozesses kann SQL Server die Datenbank online schalten und für lesende oder schreibende Zugriffe freigeben. Da der Recovery-Prozess bei großen und sehr aktiven Datenbanken durchaus eine längere Weile dauern kann, gibt es in jüngeren Programmversionen des SQL Server einige Optimierungen dazu. Das Recovery erfolgt beispielsweise auch beim Failover eines SQL-Clusterservers, wodurch die Umschaltzeit auf den Failover-Knoten manchmal unerwartet lang dauern kann.

Restore: Manuell nach Datenverlust

Der “Restore”-Prozess bezeichnet die manuelle Wiederherstellung einer SQL-Server-Datenbank nach einem Datenverlust, also das Gegenstück zum Backup. Hierzu gibt es eine Reihe von Methoden, aus denen der Admin je nach Situation die geeignete auswählen muss.

Daten sichern und wiederherstellen

Für Datensicherung und -wiederherstellung bietet SQL Server mehrere Methoden, die teilweise auf dem Transaktionsprotokoll beruhen. Alle Methoden eignen sich für das Online-Backup, ohne dass SQL Server angehalten werden muss.

Vollständiges Backup

Das vollständige Backup sichert alle Seiten (Pages) der Datenbank auf das Sicherungsmedium und liest diese dazu direkt von der Festplatte. Durch eine leistungsfähige Priorisierung sorgt der Prozess dafür, dass Änderungen an Datenbankseiten erst dann erfolgen können, wenn die Seiten bereits gesichert wurden. Das führt natürlich dazu, dass während des Sicherungsvorgangs nicht die gesamte Performance des Datenbankservers zur Verfügung steht. Trotzdem bildet die vollständige Datensicherung die Grundlage für alle Sicherungsverfahren und sollte daher regelmäßig ausgeführt werden.

Dieser Sicherungstyp lässt sich über die grafischen Verwaltungstools oder per SQL-Kommando ausführen. Die Grundsyntax zur Ad-hoc-Sicherung in eine Datei lautet:

BACKUP DATABASE NameDerDatenbank TO DISK = 'C:\Pfad\Dateiname.bak'

Differenzielles Backup

Das differenzielle Backup sichert alle Seiten der Datenbank, die sich seit dem letzten vollständigen Backup geändert haben. Der eigentliche Sicherungsprozess entspricht dem der vollständigen Sicherung. Aufgrund des Prinzips wird der Umfang der Datensicherung tendenziell um so größer, je länger das Full Backup zurückliegt.

Auch dieser Sicherungstyp lässt sich grafisch oder per Code ausführen. Die Grundsyntax ist in diesem Fall:

BACKUP DATABASE NameDerDatenbank TO DISK = 'C:\Pfad\Dateiname.bak'
WITH DIFFERENTIAL

Transaktionsprotokoll-Backup

Die Datensicherung der Transaktionsprotokolle erfolgt auf gänzlich andere Weise. Hier sichert der Server nicht die eigentlichen Datenbank-Seiten, sondern den Inhalt des Transaktionsprotokolls. Dafür gibt es drei zwingende Voraussetzungen:

1. Das Wiederherstellungsmodell der Datenbank ist “Vollständig” (oder “Massenprotokolliert”, was aber noch einige Besonderheiten nach sich zieht)
2. Es hat mindestens eine vollständige Datenbank-Sicherung stattgefunden, seit der Modus “Vollständig” aktiviert wurde
3. Die Transaktionsprotokoll-Sicherungen erfolgen in einer Reihe ohne Unterbrechung. (Sollte einmal eine Unterbrechung nötig sein – etwa weil das Log vollgelaufen war und manuell gekürzt werden musste –, so ist zunächst wieder eine vollständige Datenbank-Sicherung nötig.)

Die Transaktionsprotokoll-Sicherung entspricht dem “inkrementellen Backup” in klassischen Umgebungen, denn sie bezieht sich immer auf die vorangegangene Protokollsicherung. Je häufiger man einen solchen Sicherungsprozess ausführt, desto geringer ist tendenziell der Umfang der einzelnen Sicherung. Damit eignet sich das Verfahren auch für Strategien mit sehr hoher Frequenz, beispielsweise alle 15 Minuten.

Natürlich lässt sich auch dieses Verfahren grafisch oder per Kommando ausführen. Die Syntax ist etwas anders als bei den anderen Varianten:

BACKUP LOG NameDerDatenbank TO DISK = 'C:\Pfad\Dateiname.bak'

Wiederherstellung

Die Wiederherstellung einer Datenbank hängt bezüglich des einzusetzenden Verfahrens von zahlreichen Faktoren ab – dazu gehören natürlich die Methoden, die für das Backup genutzt wurden. Da aber auch viele andere Besonderheiten zu berücksichtigen sind, beschränken wir uns hier absichtlich auf einige grundlegende Hinweise.

Wiederherstellung eines “Full Backup”

Der einfachste Restore-Vorgang ist die Wiederherstellung von einer vollständigen Datensicherung. Dadurch setzt man die Datenbank auf den Stand zurück, den sie beim Backup hatte. Alle Daten also, die zwischen dem Backup und dem Eintritt des Schadens geändert wurden, sind damit verloren.

“Maximale” Wiederherstellung

Um mehr als nur das letzte “Full Backup” wiederherzustellen, benötigt man als Datenbasis ein differenziertes Sicherungssystem, idealerweise kombiniert aus vollständigen und protokollbasierten Sicherungen; je nach Größe der Datenbank ggf. ergänzt um differenzielle Sicherungen. Im Fall des Falles verläuft der prinzipielle Restore-Vorgang so:

1. Wiederherstellen des letzten Full Backup
2. Falls vorhanden, wiederherstellen des letzten Differenziellen Backup
3. Wiederherstellen aller Transaktionsprotokolle, die nach dem Differenziellen Backup gesichert wurden

Wichtig dabei: Schritt 3 muss lückenlos erfolgen. Wichtig ebenso: In diesem Prozess darf der sog. “Recovery-Prozess” (siehe oben) erst nach dem letzten wiederhergestellten Transaktionsprotokoll erfolgen, er muss also vorher unterdrückt werden.

Weitere Details finden sich in der Online-Hilfe des SQL Server. Die nötigen Schritte des Restore-Prozesses sollte man regelmäßig und ausführlich üben!

Ein bisschen Best Practice

Die folgenden Hinweise verstehen sich ausdrücklich nicht als feste Empfehlungen für jede Situation, sondern nur als Faustregeln für typische, überschaubare Anforderungen.

• Für eher “einfache” Datenbanken ist es durchaus sinnvoll, das Wiederherstellungsmodell auf “Einfach” zu stellen (Recovery Model “Simple”). Auf diese Weise ist sichergestellt, dass die Log-Dateien nicht überlaufen. Die nachteilige Folge ist, dass man von solchen Datenbanken nur vollständige Backups (sowie differenzielle Backups) erzeugen kann, die Transaktionsprotokolle lassen sich in diesem Zustand nicht sichern und damit auch nicht für die Wiederherstellung einsetzen. Für viele Datenbanken ist das aber auch gar nicht nötig: Rein administrative Datenbanken etwa enthalten oft nur Konfigurationsinformationen oder statistische Daten. Im Fall eines Falles wäre es hier durchaus denkbar, nur auf den Stand des letzten Full Backup zurückkehren zu können.
• Für wirklich kritische Datenbanken hingegen ist das Wiederherstellungsmodell “Vollständig” besser geeignet – allerdings auch nur dann, wenn man einen dazu passenden Backup- und Restore-Plan implementiert (siehe oben). Ein typisches Beispiel sind hochdynamische ERP-Datenbanken, für die ein Unternehmen den Datenverlust so gering wie möglich halten muss.
• Vorsicht: Sobald das Wiederherstellungsmodell auf “Vollständig” steht, ist man verpflichtet, für ein regelmäßiges Log-Backup zu sorgen, weil sonst die Log-Dateien unweigerlich voll laufen werden. Hierzu also:
  • Direkt im Anschluss an das Umschalten auf das “vollständige Wiederherstellungsmodell” eine Komplettsicherung (Full Backup) der Datenbank erzeugen
  • Direkt danach einen regelmäßigen Log-Backup-Plan einrichten (min. einmal täglich, vielleicht öfter) – hierzu eignet sich der SQL Server Agent
  • Den entsprechenden Recovery-Plan dafür entwerfen und dokumentieren
  • Das Log Volume ständig überwachen, ob es nicht trotzdem vollläuft (je nach Transaktionsart kann es durchaus auch mal zu einem plötzlichen deutlichen Anwachsen der Logs kommen, z.B. bei Daten-Imports in eine Datenbank)

Verwandte Beiträge:

1. Exchange Server 2007 SP1 und Remote Streaming Backup
   Um eine Exchange Server Datenbank zu sichern, wird in den...
2. Windows Server Backup verstehen und nutzen
   Windows Server Backup ist das Werkzeug, das seit Windows Server...
3. Automatische Backups für SQL Server Express
   Die Express-Edition des SQL Server 2005 erfreut sich ähnlich großer...

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...

[Datenschutz: Backup-Grundlagen für Windows Server 2008 R2 | TechNet Magazine]
http://technet.microsoft.com/de-de/magazine/ff625293.aspx

Verwandte Beiträge:

1. Windows Server Backup: Einmalsicherung ungleich Sicherungszeitplan
   In Windows Server Backup hat man unter Windows Server 2008...
2. Windows Image Backup: Server-Sicherung zur Laufzeit und Wiederherstellung
   Dieser Artikel erschien zuerst auf Bents Blog. Seit Windows Server...
3. Service Pack 1 für Windows 7 und Server 2008 R2 ist RTM!
   Ich zitiere Michael Kleef vom TechNet-Blog: Windows Server 2008 R2...

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...