Virtualisierung

Sicherung und Notfallwiederherstellung für die Servervirtualisierung

Adam Fazio

Auf einen Blick:

• Überlegungen bei der Planung der Notfallwiederherstellung
• Hochverfügbarkeitslösungen für die Notfallwiederherstellung
• Sichern und Wiederherstellen mit Windows Server-BackupItem

Inhalt

Grundlagen der Notfallwiederherstellungsplanung
Notfallwiederherstellung und Virtualisierung
Konvertierung von physischen zu virtuellen Computern
Snapshots des virtuellen Computers
Sichern von Hyper-V
Windows Server-Sicherung
Sichern virtueller Computer mit WSB
Überlegungen
Wiederherstellen virtueller Computer mit WSB
Data Protection Manager
Skriptgesteuerte Sicherungen
DiskShadow
Schlussbemerkung

Mit der Weiterentwicklung der Servervirtualisierungstechnologie und der zunehmenden branchenweiten Akzeptanz erkennen Organisationen Vorteile, die weit über die beliebteste Virtualisierungsrechtfertigung hinausgehen: verringerte Infrastrukturkosten und eine erhöhte IT-Flexibilität. Das nächste Ziel besteht darin, mithilfe der Virtualisierungsplattform Notfallwiederherstellungsstrategien zu ermöglichen oder zu verbessern.

Weshalb ist die Bereitschaft zur Notfallwiederherstellung fortwährend eines der heißesten Themen für die IT-Branche? In Studien wird darauf hingewiesen, dass Unternehmen bei Ausfallzeiten einen Verlust von durchschnittlich 80.000 bis 90.000 Dollar pro Stunde erleiden und dass sehr wenige Unternehmen nach einem schwerwiegenden Datenverlust langfristig überleben. Dieser Artikel bietet anhand der Microsoft-Virtualisierungsplattform eine Einführung in die Notfallwiederherstellung sowie einen tieferen Einblick in die Optionen und Überlegungen zur Sicherung und Wiederherstellung für Windows Server 2008 Hyper-V.

Grundlagen der Notfallwiederherstellungsplanung

Die Notfallwiederherstellung ist der Prozess der Wiederherstellung wichtiger Dienste im Falle eines Ausfalls und sollte ein Teil des Geschäftskontinuitätsplans jedes Unternehmens sein. In solch einem Plan wird definiert, wie das Unternehmen während oder nach einem Notfall seinen Betrieb aufrechterhalten wird. Diese Pläne sind der Grundstein jeder Notfallwiederherstellungsinitiative.

Einige Anbieter behaupten, dass ihre Automatisierungstechnologie für die Notfallwiederherstellung den Bedarf an einem ausführlichen und gut geprobten Plan verringert oder überflüssig macht. Es trifft zwar zu, dass Automatisierung die Wiederherstellungszeiten verbessern und die Abhängigkeit von Eingriffen des Menschen verringern kann. An dieser Stelle ist es jedoch Zeit für eine öffentliche Bekanntmachung: Sie können das Risiko eines Notfalls mit Technologie allein nicht erfolgreich begrenzen. Die Personen und Prozesse sind immer so wichtig wie die Technologien.

Genau genommen, werden Sie es fast unmöglich finden, die richtigen Technologien auszuwählen, ohne zuerst alle Einschränkungen und Ziele zu kennen, die sich aus dem Notfallwiederherstellungsplan ergeben. Aus Platzgründen kann in diesem Artikel kein vollständiger Notfallwiederherstellungsplan definiert werden, aber die Elemente, die für die Auswahl der richtigen Technologien und Implementierungen notwendig sind, sollen hier hervorgehoben werden. Im Folgenden sollen einige wichtige Technologietreiber, die in keinem Notfallwiederherstellungsplan fehlen dürfen, kurz beschrieben werden.

Dienstdefinitionen und Priorisierung Was genau definiert den gesamten Dienst, den Sie zu schützen versuchen, und wie wichtig ist er für die Organisation? Abbildung 1 zeigt Beispiele für Unternehmensdienste, die wahrscheinlich in jedem Notfallwiederherstellungsplan vorkommen.

Abbildung 1 Beispiel für Dienstdefinitionen und Priorisierung

Nachdem Sie die Dienste definiert haben, können Sie beginnen festzustellen, welche Systeme und Abhängigkeiten sich für welche Art von Notfallwiederherstellungsstrategien eignen. Es könnte sein, dass Sie nach einer Prüfung aller Dienste und Abhängigkeiten feststellen, dass Sie einige verschiedene Ebenen von Notfallwiederherstellungsfunktionen in Betracht ziehen müssen, da eine einzige Notfallwiederherstellungslösung für alle erfolgsentscheidenden Dienste zu teuer und komplex wäre.

Vereinbarungen zum Servicelevel Eine Vereinbarung zum Servicelevel (Service Level Agreement, SLA) ist eine Vereinbarung oder ein Vertrag zwischen dem Dienstanbieter (IT) und dem Kunden (der Organisation), die bzw. der die Verfügbarkeitsziele für einen bestimmten Dienst definiert. Diese können sehr lang oder recht kurz und bündig sein, wie z. B. „Das E-Mail-System wird während allgemeiner Geschäftszeiten zu 99,95 Prozent der Zeit und während nicht allgemeiner Geschäftszeiten zu 98 Prozent der Zeit verfügbar sein, ausschließlich geplanter Wartungszeiten, die monatlich berechnet werden.“ Meist werden SLAs in Stufen aufgeteilt, denen die IT-Dienste zugewiesen werden können, gemessen über einen vordefinierten Zeitraum.

Vereinbarungen zum Betriebslevel Vereinbarungen zum Betriebslevel (Operating Level Agreements, OLAs) beschreiben grundsätzlich die Vereinbarungen zwischen verschiedenen IT-Gruppen, die durch ihre Arbeit eine SLA unterstützen, einschließlich des Prozesses und der Antwortzeiten für die Bereitstellung ihrer Dienste. Angenommen, Sie haben eine erfolgsentscheidende Website mit einem SLA-Ziel von 99,99 Prozent, aber eine Datenbank, von der sie inhaltsmäßig abhängt, hat nur ein Verfügbarkeitsziel von 95 Prozent. Die OLA ist nützlich bei der Klärung dieser Nichtübereinstimmung und beim Ausrichten der IT-Teams auf das gleiche Ziel.

Wiederherstellungspunktziele und Wiederherstellungszeitziele Ein Wiederherstellungszeitziel (Recovery Time Objective, RTO) definiert, wie lange ein Dienst nicht verfügbar sein kann, bevor eine Lücke in der Kontinuität entsteht, während ein Wiederherstellungspunktziel (Recovery Point Objective, RPO) definiert, welches Maß an Datenverlust die Organisation als akzeptabel ansieht. Deshalb hat also ein Dienst mit einer SLA von 99 Prozent ein RTO von 7 Stunden und 18 Minuten pro Monat. Wenn Sie dies mit einem RPO von beispielsweise 24 Stunden kombinieren, können Sie jetzt Ihre Sicherungsverfahren und Zeitpläne genau definieren.

Datenaufbewahrungsrichtlinien Die Aufbewahrungsrichtlinien einer Organisation definieren genau, wie lange und wo die Sicherungen aufbewahrt werden. Sie werden meist von rechtlichen Anforderungen gesteuert.

Datenkategorisierung Außerdem muss die Natur der Daten in Betracht gezogen werden. Wenn Sie Ihre Daten in Kategorien einteilen, können Sie schnell sehen, dass nicht alle Daten die gleiche Priorität der Notfallwiederherstellung erfordern. Zum Beispiel kann eine einzige Datenbank andere Verfügbarkeitsanforderungen haben als ein Active Directory mit mehreren Domänencontrollern, die jeweils ein Replikat des Verzeichnisses enthalten. Ähnlich können Dateiserverdaten ganz andere Wiederherstellungsverfahren haben als CRM-Daten.

Notfallszenarios Es ist wichtig, alle Szenarios zu definieren, für die Sie planen wollen, da bei jedem Szenario andere Wiederherstellungsverfahren, Geschäftsauswirkungen und damit verbundene Kosten gegeben sind. Es ist hilfreich, alle möglichen Szenarios zu betrachten und dann zu entscheiden, auf welche Sie abzielen wollen, wenn Sie an Notfallwiederherstellungsplänen für Ihre Umgebung arbeiten:

• Verlust einer gesamten Website
• Verlust eines einzigen Datencenters
• Verlust eines Systems (Betriebssystem- oder Hardwareausfall)
• Verlust von Daten (Datenlöschung oder -beschädigung)
• Verlust einer wichtigen Abhängigkeit

Offensichtlich gibt es sehr unterschiedliche Überlegungen, was das Wiederherstellen bei einem Verlust einer gesamten Website im Gegensatz zu einem einzigen System angeht. Außerdem empfiehlt sich die Definition der Schwellenwerte für die Wiederherstellung auf Grundlage Ihrer SLAs. Angenommen, dass beispielsweise eine gesamte Website aufgrund eines größeren ISP-Netzwerkausfalls offline ist. Wenn die SLA für den betroffenen Dienst 8 Stunden für die Dienstwiederherstellung vorsieht und 48 Stunden für die Datenwiederherstellung, würden Sie gegebenenfalls Dienstfailoververfahren für Ihre Sicherungswebsite durchführen, aber den Datenwiederherstellungsprozess nicht tatsächlich durchlaufen, da Sie ein recht schnelles Failback zur Produktionswebsite erwarten würden.

Nicht schlecht! All diese Arbeit, und von Technologie war noch gar nicht die Rede. Die Bedeutung des Planens darf nicht unterschätzt werden. Eine Implementierung der Notfallwiederherstellung ohne einen dokumentierten Plan ist nur eine „Notfallwiederherstellungshoffnung“.

Notfallwiederherstellung und Virtualisierung

Nachdem jetzt die Grundlagen für die Notfallwiederherstellungsplanung gelegt sind, bleibt die Frage, was die Virtualisierung beizutragen hat. Viele Unternehmen melden die Wiederherstellungszeiten für Berichtsdienste mit virtualisierten Servern in Minuten im Gegensatz zu Tagen oder Wochen für ihre physischen Entsprechungen. Weil das gesamte Serverbetriebssystem jetzt nur ein Satz von Dateien ist, die von der zugrunde liegenden Hardware abstrahiert werden, öffnen sich neue Türen, was die Wiederherstellbarkeit betrifft.

Eine heute weit verbreitete Theorie lautet, dass einige oder alle Notfallwiederherstellungsziele mit Hochverfügbarkeitslösungen erreicht werden können. Die Idee dahinter ist folgende: Bei Clusterknoten an separaten physischen Speicherorten, wobei Daten zwischen den Websites synchronisiert werden, kann im Falle eines Fehlers der passive Knoten wieder Vorgänge aufnehmen, und Sie können nahezu in Echtzeit wiederherstellen.

Dies ist wahr, aber wenn Sie sich die oben definierten Notfallszenarios ins Gedächtnis rufen, ist klar, dass dies keine Lösung für alle Szenarios ist. Sie benötigen eine Kombination von Technologien, um sich auf alle Szenarios vorzubereiten, und dies umfasst in der Regel eine Form von regelmäßigen Sicherungen. Hohe Verfügbarkeit schützt nicht vor allen möglichen Ausfällen und schließt den Bedarf an einer Form von Sicherungsstrategie nicht vollständig aus.

Hohe Verfügbarkeit mit Hyper-V erfordert, dass Sie die Speicherschicht sorgfältig planen, weil dies ein entscheidender Faktor ist, damit die Wiederherstellung erfolgen kann. Zum Beispiel hat ein 2-Knoten-Hyper-V-Cluster mit freigegebenem Speicher immer noch das Speichersubsystem und die Daten als einzelne Fehlerquelle, selbst wenn sich die Clusterknoten in separaten Datencentern befinden.

Sie sollten jedoch wissen, dass der gleiche 2-Knoten-Hyper-V-Cluster mit nicht freigegebenem Speicher den Speicher- oder Datenverlust auf einem der Knoten überleben kann. Dies erfordert Replikationstechnologien, um den Speicher in einem synchronisierten Zustand zu halten, und es ist mit einigen Komplexitäten verbunden (siehe Abbildung 2).

Abbildung 2 Mehrfachstandort-Hyper-V-Cluster (zum Vergrößern auf das Bild klicken)

Es gibt einige sehr interessante Entwicklungen im Bereich der Datenreplikation und -synchronisierung, die aber von Microsoft derzeit nicht angeboten werden. Es lohnt sich, auf der Seite zum Mehrfachstandortclustering in Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) einen Blick auf die präsentierten Partner zu werfen. Eine andere Ressource ist der Windows Server-Katalog (siehe windowsservercatalog.com), in dem die Speicherhersteller mit für Windows Server 2008 zertifizierten Replikationstechnologien aufgelistet werden.

Wie Sie sehen können, gibt es viele verschiedene Hochverfügbarkeits- und Speicherkonfigurationen, die in Betracht kommen. Dies ist wiederum der Grund, weshalb Sie dafür sorgen müssen, dass Ihre Geschäftsanforderungen definiert sind, sodass diese die technischen Anforderungen steuern und nicht umgekehrt.

Konvertierung von physischen zu virtuellen Computern

Virtualisierung bietet offensichtlich eine einmalige Wiederherstellungsflexibilität, aber was ist mit physischen Systemen, die keine guten Virtualisierungskandidaten sind? Zu System Center Virtual Machine Manager (SCVMM) gehört die Möglichkeit, Konvertierungen von physischen zu virtuellen (P2V) Windows-Servern durchzuführen, die einen startbaren virtuellen Hyper-V-Computer ergeben, der ein genaues Replikat des physischen Quellservers ist. Jetzt können Sie diesen virtuellen Computer so wie seine virtualisierten Entsprechungen auf dem Campus oder im restlichen Land replizieren und ähnliche Wiederherstellungszeiten erreichen.

Dieser Ansatz unterscheidet sich insofern von einer traditionellen Bare-Metal-Wiederherstellung, als Ihr Wiederherstellungsspeicherort nicht mehr die gleiche Anzahl oder die gleiche Art physischer Systeme wie Ihr Produktionsspeicherort benötigt. Sie können also Ihre Wiederherstellungshardware überbeanspruchen und sie nach Bedarf anpassen, je nachdem welche Auswirkung der Notfall hat.

Obwohl SCVMM keinen Planer für P2V-Konvertierungen enthält, da die grafische Benutzeroberfläche vollständig auf Grundlage von Windows PowerShell ausgeführt wird, kann dies problemlos mit dem New-P2V-Cmdlet programmiert werden. Genau genommen, zeigen alle Assistenten in SCVMM den zur Ausführung eines Auftrags verwendeten Code an, und Sie können den Code von einer Test-P2V in Ihrer Umgebung kopieren und sie für die zukünftige automatisierte Verwendung ändern. Abbildung 3 zeigt einen Beispielcode. Sie können den SCVMM P2V-Assistenten in Ihrer Umgebung ausführen, um ein eindeutiges, anpassbares Windows PowerShell-Skript zu erhalten.

Abbildung 3 Vom SCVMM-P2V-Assistenten bereitgestellter Code

$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>" 
-Credential $Credential -RunAsynchronously 

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F" 
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External" 
-MachineConfig $MachineConfig 

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig 

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path 
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig 
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM 
-UseHardwareAssistedVirtualization $false -StopAction SaveVM 

Snapshots des virtuellen Computers

Obwohl er technisch gesehen keine Sicherung darstellt, stellt ein Snapshot eines virtuellen Computers einen Zeitpunkt bereit, den Sie wiederherstellen können, indem Sie differenzierende Datenträger und eine Kopie der Konfigurationsdatei des virtuellen Computers verwenden. Wenn der Notfall zufällige Datenlöschungen innerhalb des virtuellen Computers umfasst, kann dies als ein Notfallwiederherstellungsfeature betrachtet werden, da der virtuelle Computer auf den Snapshot zurückgesetzt und der Schaden rückgängig gemacht werden kann. (Snapshots des Volumeschattenkopie-Diensts (Volume Shadow Copy Service, VSS) werden weiter unten behandelt.)

Sichern von Hyper-V

Hostbasierte Sicherungen Ein interessanter Vorteil, den die Servervirtualisierung bietet, ist die Aussicht darauf, die virtualisierten Systeme nicht mehr individuell sichern zu müssen. Nun, da diese Systeme einfach Dateien sind, die sich auf dem Dateisystem eines Hosts befinden, könnten Sie einfach eine Sicherungskopie der Dateien erstellen und hätten alles erledigt, oder? Nicht so ganz. Weil es sich um Livecomputer handelt, die aus speicherinternen Daten, Daten auf Datenträgern, Systemkonfigurationen und offenen Dateien bestehen, muss einiges beachtet werden. Wie wird also die Konsistenz der Sicherungsdaten gewährleistet angesichts all dieser beweglichen Teile?

Eine erhebliche Verbesserung der Windows Server-Sicherung ging mit Windows Server 2003 und der Veröffentlichung von VSS einher. VSS bietet einen Standardsatz erweiterbarer APIs, die VSS-Schreiber (Hooks in Anwendungen und Diensten, die für die Bereitstellung konsistenter Schattenkopien nützlich sind) verwenden, um Sicherungen offener Dateien und Anwendungen zu erstellen. Mit dem VSS, den VSS-Anbietern und -Schreibern kann die Sicherungsanwendung sehr schnell eine zeitpunktgenaue Kopie eines Volumes erstellen, eine Kopie, die die Anwendung erkennt und entsprechend verarbeiten kann.

Hyper-V verfügt über seinen eigenen VSS-Schreiber, der Softwareherstellern ermöglicht, überzeugende Sicherungslösungen zu erstellen. Der Schreiber ermöglicht, dass Sicherungsanwendungen hostbasierte VSS-Sicherungen aktuell ausgeführter virtueller Computer erzielen. Wenn in dem im virtuellen Computer ausgeführten Betriebssystem die Hyper-V-Integrationskomponenten und der VSS (verfügbar in Windows XP SP1 und Windows Server 2003 und höher) installiert sind, findet die hostbasierte Sicherung so statt, als ob sie innerhalb des Gasts ausgeführt wird. Die Sicherung wird durchgeführt, während der virtuelle Computer ausgeführt wird, und die Daten sind konsistent (siehe Abbildung 4).

Abbildung 4 VSS-Sicherung (zum Vergrößern auf das Bild klicken)

Wenn das Gastbetriebssystem jedoch die Integrationskomponenten oder den VSS nicht unterstützt, erfordert der Sicherungsprozess, dass der Gastcomputer in einen gespeicherten Zustand versetzt wird und dass ein hostbasierter VSS-Snapshot der Datendateien des virtuellen Computers erstellt wird, der für eine zeitpunktgenaue Wiederherstellung verwendet werden kann. Bei VSS-Snapshots mit gespeichertem Zustand fällt eine Ausfallzeit des virtuellen Computers an (kann in der Regel auf 5–10 Minuten begrenzt werden), wobei vollständige Sicherung-auf-Band-Verfahren anhand der VSS-Kopie der Daten stattfinden.

Gastbasierte Sicherungen In einer physischen Umgebung müssen Server und Anwendungen individuell gesichert werden, und solche Sicherungen können sicherlich in einem virtualisierten Datencenter fortgesetzt werden. In dieser Situation müssen die gleichen Überlegungen berücksichtigt werden wie beim Erstellen einer Sicherungskopie eines virtuellen Computers, wie z. B. Netzwerkkapazitätsanforderungen für netzwerkbasierte Sicherungen und Leistungsauswirkungen auf das System während des Sicherungsfensters. Mit gastbasierten Sicherungen können Sie eine dedizierte physische Netzwerkschnittstellenkarte (Network Interface Card, NIC) im Host einrichten, die an ein virtuelles Netzwerk gebunden ist, das alle Gäste verwenden.

Windows Server-Sicherung

Windows Server 2008 umfasst die VSS-fähige Windows Server-Sicherung (Windows Server Backup, WSB), die verwendet werden kann, um host- und gastbasierte Hyper-V-Sicherungen Ihrer virtuellen Computer durchzuführen. Weil sie vollständig VSS-fähig ist, kann sie hostbasierte Sicherungen Ihrer virtuellen Computer durchführen, was natürlich vorzuziehen ist.

Bei virtuellen Computern ohne installierte Integrationskomponenten wird VSS jedoch nicht verwendet. In dem Fall stehen Ihnen einige Optionen zur Verfügung. Sie können weiterhin WSB verwenden, um eine Sicherungskopie eines virtuellen Computers zu erstellen, auf dem die Integrationskomponenten nicht installiert sind. Das heißt, der Zustand des virtuellen Computers wird gespeichert, und die Sicherung erfasst dann die virtuellen Datenträger und Konfigurationsdateien des virtuellen Computers.

Dies ist jedoch unter Umständen bei einer Anwendung wie z. B. Exchange nicht wünschenswert, weil die Anwendung nicht erkennt, dass eine Sicherung ausgeführt wurde, sodass Anwendungsprotokolle nicht gekürzt werden. Außerdem fällt auf dem virtuellen Computer eine Ausfallzeit an, die je nach Dauer der Sicherung unterschiedlich ausfällt.

Alternativ kann eine Sicherung von innerhalb des virtuellen Computers ausgeführt werden, so als ob es sich um einen physischen Computer handelt, wobei entweder NTBackup oder WSB verwendet wird, je nach Betriebssystem des virtuellen Computers. Als Nächstes wird untersucht, wie WSB für unterstützte Gäste verwendet wird, auf denen die Integrationskomponenten installiert sind.

Sichern virtueller Computer mit WSB

Hyper-V registriert seinen VSS-Schreiber nicht automatisch für die Verwendung mit WSB. Sie müssen den in Abbildung 5 gezeigten Registrierungsschlüssel und -wert manuell hinzufügen, damit WSB eine Hyper-V-Sicherung unterstützt. Sie können sie über die Befehlszeile hinzufügen, etwa so:

reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v

Abbildung 5 Schlüssel und Wert für das Registrieren des Hyper-V-VSS-Schreibers

Dies erfordert keinen Neustart, da WSB diesen Schlüssel/Wert zur Sicherungslaufzeit sucht. Der folgende Befehl wird angezeigt, wenn der Eintrag festgelegt wurde:

reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s

Hier ist die Vorgehensweise zum Installieren von WSB. Klicken Sie auf „Start“ | „Server-Manager“. Klicken Sie im linken Fensterbereich auf „Features“ und anschließend im rechten Fensterbereich auf „Features hinzufügen“. Erweitern Sie auf der Seite „Features auswählen“ die Windows Server-Sicherungsfeatures, und aktivieren Sie die Kontrollkästchen für Windows Server-Sicherung und Befehlszeilentools. Führen Sie jetzt die folgenden Schritte aus, um Ihre Sicherung zu konfigurieren:

1. Gehen Sie zu „Start“ | „Verwaltung“ | „Windows Server-Sicherung“.
2. Wenn Sie eine Sicherungskopie eines Remotehosts erstellen, wählen Sie „Verbindung mit anderem Computer herstellen“ aus, und geben Sie den Hyper-V-Host ein.
3. Wählen Sie entweder „Einmalsicherung“ oder „Sicherungszeitplan“ aus.
4. Wählen Sie die Sicherungskonfiguration aus, entweder „Vollständiger Server“ oder „Benutzerdefiniert“. Wenn Sie „Benutzerdefiniert“ auswählen, stellen Sie sicher, dass Sie alle Volumes abrufen, die Daten enthalten, die sich auf den zu sichernden virtuellen Computer beziehen, einschließlich der Konfigurationsdaten, der virtuellen Datenträger und der Snapshots des virtuellen Computers.
5. Wählen Sie den Speicherort aus, um die Sicherung zu speichern.
6. Wählen Sie entweder „Vollständige VSS-Sicherung“ oder „VSS-Kopiesicherung“ aus. Wählen Sie für hostbasierte Sicherungen, bei denen keine anderen Sicherungen mit den virtuellen Computern stattfinden, die Option „Vollständige VSS-Sicherung“ aus.
7. Wählen Sie, nachdem Sie die Details bestätigt haben, die Option „Sicherung“ aus.

Überlegungen

• Sie müssen eine Sicherungskopie aller Volumes erstellen, die sich auf einen virtuellen Computer beziehen, einschließlich Virtueller Festplatten (Virtual Hard Disks, VHDs), Konfigurationsdateien und Snapshots virtueller Computer.
• Wenn Sie einen Sicherungszeitplan erstellen, müssen Sie ein dediziertes lokales Volume verwenden, das ausschließlich von WSB formatiert und verwendet wird. Wenn Sie im Gegensatz dazu einen Einmalsicherungsauftrag durchführen, können Sie die Sicherung auf einem nicht dedizierten lokalen Volume, einem Wechseldatenträger oder einer Netzwerkfreigabe speichern.
• Wenn die Integrationskomponenten nicht innerhalb des zu sichernden virtuellen Computers installiert sind, speichert WSB den Zustand des ausführenden virtuellen Computers, um die Datenkonsistenz der Sicherung sicherzustellen.
• Nach Abschluss ist der Sicherungssatz übertragbar und kann mit jedem Hyper-V-Host verwendet werden.

Wiederherstellen virtueller Computer mit WSB

Obwohl WSB die Fähigkeit hat, einzelne Dateien wiederherzustellen, verwendet dieses Feature nicht VSS und könnte deshalb eine inkonsistente Wiederherstellung zur Folge haben, wenn der virtuelle Computer zum Zeitpunkt der Sicherung ausgeführt wurde. Zum Wiederherstellen gerade ausgeführter virtueller Computer müssen Sie das gesamte Volume (bzw. alle Volumes) wiederherstellen.

Gehen Sie hierfür zu „Start“ | „Verwaltung“ | „Windows Server-Sicherung“, und wählen Sie im Aktionsbereich die Option „Wiederherstellen“ aus. Wählen Sie den Server aus, der die wiederherzustellenden Daten enthält (den Server, auf dem sich die WSB-Sicherungsdaten befinden), und wählen Sie das Datum der wiederherzustellenden Daten aus. Jetzt können Sie den Wiederherstellungstyp auswählen.

Hier muss eine Entscheidung getroffen werden. Wenn Sie den gesamten virtuellen Computer benötigen, einschließlich seiner Konfiguration, der Snapshots und der virtuellen Datenträger (z. B. bei einem vollständigen Hostausfall), wählen Sie die Anwendungswiederherstellung und anschließend „Hyper-V“ aus (siehe Abbildung 6). In diesem Fall steht Ihnen die Option zum Wiederherstellen einzelner Dateien nicht zur Verfügung. Sie müssen alles wiederherstellen, was in diesem Sicherungssatz enthalten ist. Beachten Sie, dass dadurch die vorhandenen Konfigurationsdaten von Hyper-V und des virtuellen Computers, die sich seit der Sicherung geändert haben, nicht überschrieben werden.

Abbildung 6 Wiederherstellen einer Hyper-V-Sicherung (zum Vergrößern auf das Bild klicken)

Wenn Sie nur die VHD benötigen und die Konfigurationsdaten und Snapshots für den virtuellen Computer unbeschädigt sind, können Sie unter „Dateien und Ordner“ die benötigte einzelne VHD-Datei auswählen. Beachten Sie, dass bei diesem Prozess der VSS-Schreiber nicht verwendet wird. Die Sicherung des virtuellen Computers hätte dies berücksichtigen und seinen Zustand als Erstes speichern müssen.

Wenn Sie einen vollständigen System- und Datenverlust erlitten haben und den Hyper-V-Host selbst wiederherstellen müssen, einschließlich des Windows Server 2008-Betriebssystems und aller darin ausgeführten virtuellen Computer, müssen Sie in der Windows-Wiederherstellungsumgebung starten und Ihre Wiederherstellung von dort aus durchführen. Dies kann vom Windows Server 2008-Setupdatenträger oder einer vorkonfigurierten Datenträgerpartition aus durchgeführt werden.

Data Protection Manager

Es wurden für Hyper-V-Hosts und -Gäste Sicherungs- und Wiederherstellungsschritte untersucht und Überlegungen angestellt. Dabei wurde die zuverlässige und kostenlose integrierte Windows Server-Sicherung verwendet, aber WSB ist keine für Unternehmen geeignete Datenschutzlösung. Wo WSB endet, beginnt Data Protection Manager (DPM) 2007 SP1. Derzeit ist seine Veröffentlichung gegen Ende 2008 geplant. DPM SP1 wird Hyper-V unterstützen und einige überzeugende Features bieten:

• Eine einzige Verwaltungskonsole für alle Hyper-V-Hosts und -Gäste.
• Kontinuierlicher Datenschutz, der in 15-minütigen Abständen VSS-basierte Snapshots erstellt und dabei nur die geänderten Anteile berücksichtigt.
• Hyper-V-Cluster-Erkennung, die der Sicherung ermöglicht, den Bewegungen des virtuellen Computers zwischen Clusterknoten zu folgen.

• Replikation von DPM-Server zu DPM-Server.

• Unterstützung für Datenträger und Bandmedien (Datenträger zu Datenträger, Datenträger zu Band oder Datenträger zu Datenträger zu Band).
• Sicherungs- und Wiederherstellungsfunktionen über das ganze Spektrum der Daten hinweg, einschließlich Hyper-V-Hosts und -Gästen; agentlose VSS-Sicherungen aktuell ausgeführter Gäste; Unterstützung für das Wiederherstellen einzelner virtueller Computer; Failoverclusterdaten; erstklassige anwendungsspezifische Features für SQL Server, Exchange, SharePoint, Hyper-V und Virtual Server.
• Skripterstellung vor und nach der Sicherung.

Wenn Sie derzeit eine Drittanbieter-Sicherungslösung verwenden, halten Sie nach Updates für die Anwendung Ausschau, denn die meisten Anbieter arbeiten hart daran, hostbasierte Hyper-V-Lösungen auf den Markt zu bringen.

Skriptgesteuerte Sicherungen

WSB enthält eine Befehlszeilenschnittstelle (WBadmin.exe) und einen Satz von Windows PowerShell-Cmdlets für die Verwendung bei der Skripterstellung. Beim Verwenden dieser Cmdlets werden die gleichen Sicherungsregeln angewendet wie oben beschrieben. Auch hier muss der Hyper-V-VSS-Schreiber über die Registrierung manuell registriert werden.

Abbildung 7 zeigt einige WBAdmin-Befehle. Die vollständige WBAdmin-Dokumentation finden Sie unter go.microsoft.com/fwlink/?LinkId=124380. Wie Sie sehen können, gibt es nichts in WBAdmin, um die Sicherungsrichtlinie selbst zu konfigurieren, aber es gibt ein Windows PowerShell-Snap-In zum Verwalten dieser Einstellungen. Sie können mit dem folgenden Befehl testen, ob dieses Snap-In registriert ist:

Get-PSSnapin -Registered

Abbildung 7 WBAdmin-Befehle

Sie können Folgendes verwenden, um ein Snap-In namens „Windows.ServerBackup“ zu laden:

Add-PSSnapin windows.serverBackup 

Nachdem es geladen ist, haben Sie Zugriff auf die Windows PowerShell-Cmdlets für WSB (siehe Abbildung 8). Führen Sie für eine ausführliche Beschreibung der einzelnen Cmdlets den folgenden Befehl aus:

Get-Command -PSSnapin windows.serverBackup | select name | get-help –full

Abbildung 8 Cmdlets für die Windows Server-Sicherung

Es gibt ein anderes Dienstprogramm, das in Windows Server 2008 integriert ist, das auch den Hyper-V-VSS-Schreiber verwenden und Ihren Skripterstellungsoptionen Flexibilität geben kann. DiskShadow.exe ermöglicht, dass eine Schattenkopie erstellt und als Laufwerk bereitgestellt werden kann, wodurch Administratoren bei der Sicherung eine größere Auswahl haben als beim Verwenden von WSB. Denken Sie unbedingt daran, dass DiskShadow keine Eingabe über die Windows PowerShell-Pipeline akzeptiert. Stattdessen erfordert es, dass Befehle durch ein Skript übermittelt werden, was folgendermaßen aussehen könnte:

Delete Shadows Volume C:
Set Context Persistent
Begin Backup 
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow 
Create
End Backup
Expose %MyShadow% X: 
Exit

Dieses Skript löscht zuerst alle vorhandenen Schattenkopien des Laufwerks C:, und stellt dann sicher, dass die Schattenkopie beibehalten wird, nachdem DiskShadow ausgeführt wurde. Als Nächstes erstellt es einen Transaktionsblock. Falls einer der Schritte fehlschlägt, schlägt der ganze Prozess fehl. In diesem Block überprüft DiskShadow, ob der Schreiber für Hyper-V geladen ist, und fügt Laufwerk C: der Liste der zu sichernden Laufwerke hinzu.

Laufwerk C: ruft eine GUID ab, um ihn zu identifizieren, und diese GUID wird in einer Umgebungsvariablen gespeichert, die „MyShadow“ genannt wird. Sobald dies abgeschlossen ist, ist die Schattenkopie erstellt.

Die Sicherung wird mithilfe der Umgebungsvariablen als Laufwerk X: verfügbar gemacht. Mit den Daten auf X: kann Verschiedenes durchgeführt werden, und dann kann DiskShadow erneut mit dem Befehl „Unexpose X“ ausgeführt werden, um das Laufwerk zu entfernen.

Beachten Sie, dass das Wiederherstellen virtueller Computer für Hyper-V, die über DiskShadow gesichert wurden, derzeit ein manueller Prozess ist (der virtuelle Computer muss erneut aufgebaut werden, Snapshots werden nicht aufbewahrt und so weiter). Dies hat zwar einige offensichtliche Nachteile, aber die Daten sind geschützt.

Die Notfallwiederherstellung kann ein anstrengender Prozess sein, der scheinbar nie ein Ende hat. Die Servervirtualisierung bringt jedoch neue Möglichkeiten mit sich, sowohl aufgrund der Technologien als auch wegen des kostengünstigeren Einstiegs. Microsoft bietet nicht nur Virtualisierung, sondern ein gesamtes Ökosystem. Die Kombination aus Servervirtualisierungsplattform und System Center-Produktfamilie bietet ganzheitlichere Lösungen angesichts der zunehmenden komplexen Herausforderungen, denen Organisationen gegenüberstehen. Dazu gehört die Notfallwiederherstellung.

Ich möchte James O'Neill für seinen Beitrag zu diesem Artikel danken.

Adam Fazio fing vor 2 Jahren bei Microsoft Consulting Services an und ist jetzt für den US-amerikanischen öffentlichen Sektor tätig. Er stand 10 Jahre lange im Dienst der IT-Branche und hat an verschiedenen Infrastrukturprojekten und Datencentervorgängen für Fortune 100-Unternehmen und neu gegründete Internetfirmen gearbeitet. Adam Fazio ist derzeit der Leiter für technische Eskalationen für das globale Virtualization Rapid Deployment Program bei Microsoft.