Donnerstag, 23. August 2012

Windows Backup: die Zweite (Hyper-V)

Ich betreibe seit einer Weile ein Hyper-V Cluster auf Windows 2008R2 und hatte anfänglich so manche schlaflose Nacht wegen des "richtigen" Backup-Verfahrens. Teure Software gibt es reichlich, jeder verspricht andere Features, die alle extra kosten - die VMs sind sowieso einzeln zu lizensieren. Schließlich habe ich mit BackupChain eine Software gefunden, bei der ich mir nicht abgezockt vorkommen muss. (Sorry, falls der nachfolgende Text wie eine Werbeveranstaltung klingt, aber es gibt wenig Software, die wirklich hält, was sie verspricht...)

Die meisten Hyper-V Installationen werden auf iSCSI-Targets auf einem SAN aufsetzen, beim Cluster ist das bisher sogar die einzige Möglichkeit. Für eine erhöhte Datensicherheit könnte man auf der SAN-Ebene bereits ein Backup vorsehen. Einige SANs können ihren Inhalt sogar auf eine entfernte Installation spiegeln.
Leider ist diese Lösung bei meinem vorhandenen DataCore SAN ein recht teures Update so es denn überhaupt zu bekommen ist (ausgelaufener Wartungsvertrag...). Außerdem ist eine Datenspiegelung immer noch kein Backup.

Die nächste Backup-Möglichkeit wäre ein Backup aus den VMs heraus (client-based). Hier bieten sich die üblichen Verdächtigen an (ich war früher mal mit BackupExec sehr zufrieden), allerdings laufen da pro VM Kosten je nach verwendeten Features (SQL-Server, Exchange, etc.) auf.
Günstiger ist das in Windows integrierte Backup. Allerdings kann Windows auf Netzwerkfreigaben immer nur eine Backup-Generation ablegen. Hinzu käme bei einem "bare-metal" Backup eine enorme Verschwendung von Speicherplatz, da sich erfahrungsgemäß täglich nur kleine Teile einer Windows Installation ändern.
Eine Notlösung stellen Backup-Scripte dar, wie ich in einem älteren Post bereits geschrieben habe.

Also habe ich mich bei den Backup-Systemen auf dem Hyper-V Host umgeschaut (host-based). Auch hier bietet Microsoft über einen VSS-Provider die Möglichkeit nicht nur die VHDs zu sichern, sondern sogar einen Snapshot des VMs zu erstellen. Die Snaphot-Technik ist allerdings für Backup-Zwecke ungeeignet, da sie die VHDs unnötig fragmentiert (AVHDs werden erstellt) und das Aufräumen entsprechend umständlich ist, bzw. Zeit kostet.
Bleibt das VSS-Backup der VHDs. Wer schonmal versucht hat, die VHDs zu verschieben und ggfs. in einem andern Host zu starten, der weiß um die Schwierigkeiten, die dabei auf einen zukommen:

rem <ID> ist die SID des Virtuellen Systems
rem D:\VM\ ist der Speicherort meiner VM

mklink "%systemdrive%\programdata\Microsoft\Windows\Hyper-V\Virtual Machines\<ID>.xml"
    "D:\VM\Virtual Machines\<ID>.xml"

icacls "%systemdrive%\programdata\Microsoft\Windows\Hyper-V\Virtual Machines\<ID>.xml"
    /grant "NT VIRTUELLER Computer\<ID>":(F) /L

icacls "D:\VM\Virtual Harddisks\*" /T /grant "NT VIRTUELLER COMPUTER\<ID>":(F)

Mit dieser Methode kann aber eine VM nur im abgeschalteten Zustand eingespielt werden und es gibt auch nur genau eine Instanz dieser VM.

Schließlich habe ich in BackupChain eine Software gefunden, die für 199US$ pro Host meine VMs sichert:
  • moderate Softwarekosten je Host (unabhängig von der Anzahl der VMs)
  • Backup der VMs ohne Betriebsunterbrechung
  • VM-Wiederherstellung parallel zur laufenden VM möglich
  • Inkrementelle Backups durch De-Dublizierung
Die De-Dublizierung hat letztendlich den Ausschlag für die Anschaffung gegeben. Mein Backup-Medium ist ein QNAP mit 4TB Plattenplatz, und würde ich alle VMs täglich vollständig sichern, wäre der Platz nach drei Tagen belegt. Durch die eingebaute De-Dublizierung kommen täglich nur 5-10% der ursprünglichen VHD-Größe zum Backup hinzu. Einmal wöchentlich mache ich ein Full Backup, so kann ich problemlos auf eine Historie von zwei Wochen zurückgreifen.
(Es ist geplant, die QNAP Daten zusätzlich wöchentlich auf eine externe Platte zu ziehen, wodurch noch längere Aufbewahrungszeiten möglich werden).

Die Wiederherstellung importiert automatisch eine Backup-VM in den Hyper-V Manager. (Standardmäßig wird das Backup Datum an den Namen angehängt um einen doppelten Namen zu vermeiden.)
Wiederherstellung (Auswahl der VM)

Auswahl des Ziels

Wiederherstellung aus den einzelnen Backup-Generationen

Hyper-V Manager VOR der Wiederherstellung
Hyper-V Manager NACH der Wiederherstellung


Die angepriesene Unterstützung von CSV (Cluster Shared Volumes) mag technisch eine hohe Kunst darstellen (Microsoft bietet aber auch für CSV einen VSS-Provider), allerdings ist das Benutzererlebnis hier bisher noch etwas eingeschränkt, da keine Synchronisation zwischen den am Cluster beteiligten Hosts stattfindet.
D.h. jeder Host kann immer nur ein Backup der aktuell auf ihm laufenden VMs anfertigen, auch wenn er per CSV auf alle anderen Hosts zugreifen könnte. Das ist insofern etwas lästig, da man nach einer (Live)Migration einer VM immer den Backup-Job anpassen muss - auf dem Host auf den migriert wurde (der zukünftig für's Backup verantwortlich ist) und auf dem Host, von dem migriert wurde (die VM muss hier aus dem Job entfernt werden).
Der ausgezeichnete BackupChain Support hat mir versichert, in der nächsten Version (soll voraussichtlich mit Server 2012 zusammen erscheinen) wird es eine Möglichkeit für die Backup-Koordinierung zwischen einzelnen Cluster-Knoten geben.

Update (Juli 2012):
Inzwischen gibt es eine neue Minor-Version 2.4, die eine neue Lizenzabstufung einführt. Bestehende Server Lizenzen wurden automatisch in Server Enterprise Lizenzen aufgewertet, welche das neue Feature namens "Granular Backup/Restore" beinhalten.
Es ist jetzt sogar möglich bestimmte Dateien (SQL-Datenbanken, Exchange Mailboxen) "granular" aus einer laufenden VM heraus zu sichern. Allerdings ist dies mit einer Verdoppelung des Preises verbunden

Update (September 2012):
Ich habe heute die "Granular Restore" Funktion ausprobieren müssen und bin ziemlich begeistert. Musste man zuvor zunächst die VHD einer VM wiederherstellen, um dann nach der eigentlichen Datei in der VHD zu suchen, kann man jetzt direkt in die Backups der VHDs hineinschauen, anklicken und fertig!