Backup-Strategien für Hyper-V-Systeme: Teil 3

4. Oktober 2016

Bei den Datensicherungen im Hyper-V-Umfeld orientieren sich die Systembetreuer an den „klassischen“ Herangehensweisen. Lokale Backup-Medien wie Festplatten, Magnetbänder oder RDX-Speichermedien können eingesetzt werden. Allerdings sollten die aktuellen Entwicklungen beim Thema Datensicherung mit einfließen.

So ist es etwa denkbar, das bestehende Sicherungskonzept um einen weiteren Standort zu erweitern. Besonders kleinere und mittlere Unternehmen mit nur einem Standort können dank der Cloud ihre Daten an einem weiteren Ort abspeichern – im Rechenzentrum des Backup-Anbieters.

Nachdem bereits viele Workloads, Dienste und ganze VMs in die Cloud ausgelagert werden, ist es nicht verwunderlich dass einige Firmen diesen weg auch beim Thema Backup bestreiten. Die Nachteile dieser „Online-Backups“ wurden bereits in Teil 1 und Teil 2 dieser Beitragsreihe angesprochen. Doch es sind auch einige Vorteile zu nennen. Denn auf diese Weise „gewinnen“ die Unternehmen ja quasi einen weiteren „Standort“ hinzu: das Rechenzentrum des Cloud-Anbieters. Zudem können die Speicher-Volumina beinahe beliebig skaliert werden, steigt der Bedarf, dann wird das Kontingent erhöht.

Falls es zu einem Zeitpunkt wieder sinken sollte, verringern die Cloud-Anbieter den gemieteten Speicherplatz entsprechend. Auch viele namhafte Backup-Software-Anbieter haben das „Cloud-Backup“ in ihr Portfolio mit aufgenommen, und bieten oftmals mit ihren Software-Produkten auch gleich den passend angebundenen online-Speicherplatz an. Allerdings kommt es (besonders bei der ersten Vollsicherung, „Initial Seed“) oftmals zu langen Wartezeiten, wenn zig dutzend Terabyte an Daten durch (verhältnismäßig) langsame Internetleitungen zum Cloud-Anbieter übertragen werden müssen.

Geringe Bandbreiten gefährden Cloud-Backups

Einige Anbieter haben das Problem erkannt, und bieten es ihren Kunden an, diese Erstsicherung auf einer Festplatte (etwa per Kuriers) zu „übertragen“. Bei den folgenden Sicherungen, ist die verfügbare Internet-Bandbreite (meist) ausreichend, schließlich werden an dieser Stelle oftmals nur die zuletzt getätigten Änderungen übertragen (etwa bei inkrementellen Sicherungskonzepten). Bleibt allerdings noch das Problem, dass eine komplette Rücksicherung im Umkehrschluss ebenfalls sehr lange dauern würde, oder der Hersteller ebenfalls wieder einen Kurier beauftragen muss, um die aktuelle Sicherung auf einem entsprechend dimensionierten Speichermedium zu übergeben. Auch sind rechtliche Grundvoraussetzungen bei diesen Online-Dienste – zumindest im nationalen Umfeld – ein wichtiges Thema: Denn entsprechende Datenschutzgesetze schreiben vor, das personenbezogene Daten das Land beziehungsweise (unter Umständen) das Unternehmen „nicht verlassen“ dürfen.

Weiterhin bieten sich Netzlaufwerke für die Datensicherung in den Unternehmen an. Denn oftmals sind derartige Speicherressourcen bereits (etwa per Gruppenrichtlinie) an den Clients und Servern angebunden. Auf diese Weise stellen viele Unternehmen ihren Mitarbeitern einen zentralen Speicherplatz bereit. Generell werden an dieser Stelle zwei unterschiedliche Technologien eingesetzt. Häufig werden diese  Laufwerke als NAS (Network Attached Storage) oder als San (Storage Area Network) ausgeführt:

Network Attached Storage

Bei einem NAS wird quasi nur ein „Ordner“ freigegeben, und dieser (beispielswiese unter Windows) als „Laufwerk“ hinzugefügt. Auf dem NAS-Server werden intern entsprechende Dateisysteme, Partitionen und Ordner angelegt. Der Client dagegen „sieht“ nur den jeweiligen, vom NAS-Server freigegebenen Ordner, und hat damit keinen Zugriff auf die darunter liegenden Schichten. Dies kommt in vielen Organisationen zur Anwendung.

Die Netzwerkverbindung wird meist über die „normalen“ LAN- beziehungsweise Ethernet-Verkabelung hergestellt. Sprich es existiert meist keine dedizierte Speicher-Netzwerkleitung, das NAS-Laufwerk teilt sich somit die Netzwerkbandbreite mit anderen Diensten wie etwa Internet oder internen Netzwerkressourcen (Datenbanken, Email-Server). Im Hintergrund könne als NAS-Server sowohl kleinere Externe Festlatten mit LAN-Anschluss, mittlere NAS-Gehäuse oder größere Server mit dutzenden oder mehr Laufwerksschächten eingesetzt werden.

Somit lassen sich kleinere NAS-Laufwerke an den Clients (etwa nur einige wenige GByte Speicherkapazität) bis hin zu sehr großen Datenmengen (beispielsweise 100 TByte) anbinden. Ein weiterer Vorteil: Die NAS-Server lassen sich mit unterschiedlichen Betriebssystemen realisieren, etwa mit Linux oder Windows als Basis. Folglich lässt sich das NAS flexibel skalieren, und den tatsächlichen Gegebenheiten anpassen.

Allerdings werden die Daten ja über die „normale“ Netzwerkverbindung übertragen. Somit werden die Übertragungsraten meist deutlich begrenzt. So lassen sich etwa mit den typischen 1-GBit/s-Ethernet-Leitungen meistens nur Datenraten von 80 MByte/s bis 100 MByte/s (oder auch weniger) erreicht, obwohl rechnerisch bis zu 125 MByte/s möglich wären. Dazu kommt noch, dass (besonders kleinere) NAS-Systeme diese Bandbreite nicht ausreizen können. Auch die Anzahl und Anordnung der Festplatten im NAS (etwa als RAID-Konfiguration) oder die eingesetzten Festplatten-Typen (etwa „langsame“ HDDs mit 4500 Umdrehungen pro Minute, RPM) müssen dabei berücksichtigt werden.

Storage Area Network

Anders verhält sich die Anbindung per SAN: Denn auf diese Weise bekommt das Client-System Zugriff aus das zugrunde liegende Dateisystem. Der Datenzugriff wird auf Datenblock-Ebene abgewickelt, und erzeugt einen geringeren Overhead als beispielsweise bei NAS-Systemen.  Trotz dieses direkten Zugriffs kann ein SAN gleichzeitig mit mehreren anderen Systemen verbunden werden – analog zum NAS. Als Netzwerkinfrastruktur werden für SAN-Systemen dedizierte Übertragungswege eingesetzt. Sprich es wird extra für die Speicheranbindung ein oder mehrere Netzwerkleitungen reserviert. Diese können über Fiber Channel (FC) oder auch über Kupferleitungen realisiert werden. Besonderes in kleinen und mittleren Unternehmen werden oftmals nicht (teure) FC-Komponenten eingesetzt, sondern (günstigere) Netzwerkkomponenten auf Ethernet-Basis (beispielsweise iSCSI).

Während FC direkt auf die Datenübertragung an ein Speichersystem zugeschnitten ist (geringer Overhead), werden die zu übertragenden Datenblöcke bei iSCSI nicht ganz so effizient „verpackt“. Dies resultiert in einem etwas mehr Overhead, daher werden oftmals größere Ethernet-Datenpakete erstellt. Diese „Jumbo-Frames“ werden bis zu einen MTU-Wert (Maximum Transmission Unit) von 9000 Bytes eingesetzt (statt 1500 Bytes).

Dabei müssen allerdings alle Zwischenstationen oder Hops, diese Jumbo-Frames ebenfalls unterstützen (etwa die eingesetzten Switches). San-Systeme werden oftmals in mittleren oder größeren IT-Installationen eingesetzt. Denn die maximale Transferbandbreite sowie die Gesamtkapazität erlaubt (meist) eine deutlich höhere Kapazität als beispielsweise bei NAS-Systemen üblich ist.

Bei diesen Netzwerk-Lösungen können die Systembetreuer zwar unterschiedliche „Speicherbereiche“ anlegen, und beispielsweise mehrere Ordner mit einem NAS realisieren. Dabei definieren die Administratoren beispielsweise bestimmte Ordner auf dem NAS für die Mitarbeiter-Clients, und legen andere für die Server im Hintergrund fest. Auf diese Weise lassen sich beispielsweise die Arbeitsdaten für die Mitarbeiter von den Serverdaten (wie etwa Backup-Datensätzen) trennen.

Falls nun die User oder etwaige Schadsoftware diese Daten unbrauchbar machen, sind die Server-Backups davon etwa nicht betroffen. Dies ist auch mit SAN-Speicher möglich, hier lassen sich ebenfalls unterschiedliche Bereiche definieren, und die Zugriffe entsprechend eingrenzen, damit an die Clients nur die vorgesehenen Daten verfügbar sind.

Oftmals werden diese Technologien auch gemischt eingesetzt, etwa ein SAN für die (ressourcenintensiven) Server, auf denen Workloads wie etwa Datenbanken, Datensicherungen oder Email-Server zugreifen. Für die „normalen“ Clients der Mitarbeiter reicht oftmals ein zusätzliches NAS aus, besonders wenn von dieser Seite aus nur geringe Übertragungsgeschwindigkeiten benötigt werden.

Backup-Appliances

Zusätzlich sind in den Unternehmen noch dedizierte Backup-Appliances anzutreffen. Diese kommen mit eigenem Betriebssystem (Linux, Windows), und oftmals mit einer großen Anzahl an Festplatten, SSDs oder Bandbibliotheken. Somit werden sehr hohe Speicherkapazitäten erreicht. Diese Backup-Server sind in der Regel für den jeweiligen Serverschrank (19-Zoll-Rack) oder auch als Bladeserver ausgeführt.

Noch größere Systemen belegen einen kompletten Serverschrank, und bieten dann meist Speicherkapazitäten im PByte-Bereich. Auf den Clients werden hier oftmals kleinere Software-Komponenten (Agenten) installiert. Diese steuern – im Zusammenspiel mit der „Server-Komponente“ auf der Appliance die Backup- und Restore-Vorgänge.

Besonders für Hyper-V-Systeme sind dabei allerdings Lösungen interessant, die ohne Agenten in den Parent-Partitionen entsprechende Sicherungen ermöglichen. Sprich in den einzelnen VMS werden keine weiteren Software-Komponenten benötigt. Die Systeme werden somit nicht unnötig weiter belastet. In diesen Fällen wird die Sicherung der VMs direkt über den Hypervisor abgewickelt.

Bei vielen dieser Backup-Appliances müssen allerdings unterschiedliche Lizenzierungsmodelle beachtet werden, beispielsweise werden teilweise zusätzliche Gebühren für die einzelnen VMs erhoben, oder es wird über die zur Verfügung gestellte Backup-Speicherkapazität abgerechnet. Auf weitere Besonderheiten bei der Datensicherung von Hyper-V-Systemen geht das Team von NT4ADMINS im vierten Teil der Beitragsreihe ein.

Florian Huttenloher

Lesen Sie auch