Ein Backup für Hochverfügbarkeit

Cloud-Backup - Vision oder Wirklichkeit?

Seit Jahrzehnten beschäftigt sich die IT im Umfeld von Backup mit dem Thema Hochverfügbarkeit. Das beste Backup nützt nichts, wenn es bei einem lokalen Desaster mit zerstört würde. Deshalb wird ein zweiter Backupsatz (oft auf Magnetbändern) erzeugt und in einer externen Lokation hinterlegt.

Heutzutage geht der Trend sogar dahin, ein Backup in dritter Kopie an einem überregionalen Standort zu hinterlegen. Doch die Hochverfügbarkeit des Backupmediums alleine zu betrachten wäre fahrlässig, denn ebenfalls die Systeme, die das Backup erstellen sollten hochverfügbar ausgelegt sein. Diese Systeme sind in der Regel Bandlaufwerke – meist in Kombination mit einer Tape-Library zur Automatisierung – oder auch sogenannte „Virtual Tape Libraries“ die per interner Kontrolleinheit logische, also per Software emulierte, Bandlaufwerke und Bandmedien vom Backupserver abbilden. Durch die Softwareemulation sind eine hohe und parallele Anzahl von logischen Bandlaufwerken und Bandmedien darstellbar.

Zur Ablage der logischen Bänder auf „echtem“ Speicher kommen heutzutage zwei Ansätze in Betracht:

Virtual Tape Library (VTL): die logischen Bandbestände werden auf internen Disksystemen gespeichert; zuvor meist komprimiert oder dedupliziert um Speicherplatz auf der Festplatte zu sparen.

Virtual Tape System (VTS): die logischen Bandbestände werde auf internen, schnellen und kleinen Disksystemen zwischengespeichert, vollautomatisch auf kostengünstige Magnetbänder extern ausgelagert und bei Bedarf zurück geladen.

Solche virtuellen Tape-Systeme können meist auch miteinander arbeiten und Daten selbständig von einem System auf das andere replizieren. Somit befriedigen zwei geclusterte virtuelle Tape-Systeme den Aspekt Hochverfügbarkeit von Daten und Backupsystem. Solche Systeme haben sich in der Welt von Großrechner und Mainframe seit mehr als einem Jahrzehnt etabliert. Anbieter wie beispielsweise IBM gehen noch einen Schritt weiter und können bis zu sechs dieser virtuellen Systeme zu einem sogenannten Grid zusammenschalten, wobei die einzelnen Knoten (genannt Cluster) wahlweise aus reinen „Platten“-betriebenen Systemen, Backend-Tape-Library betriebenen Systemen oder gemischten Systemen bestehen können – man spricht dann von einem Hybrid-Grid. In so einem Verbund können die einzelnen Knoten an den verschiedenen Standorten spezialisierte Aufgaben übernehmen.
Allerdings trennt sich gerade im Betrieb, der Wartung und im Fehlerfalle die Spreu vom Weizen. Denn entscheidend ist im Fehlerfalle – sei es durch das Backupmedium, die -hardware oder auch im Wartungsfall – dass die Produktionsabläufe nicht beeinflusst werden und kein manueller Eingriff oder Anpassung am Host notwendig wird. So ein Eingriff könnte etwa das Aufbrechen des Spiegels (wenn die virtuellen Tape-Systeme im Backend mit Plattenspiegelung arbeiten) sein oder das Offline setzen der Tape-Devices im Fehlerstandort bzw. das Online setzen der Tape-Devices im Desaster Recovery-Standort. Im Idealfall sollte dies automatisch erfolgen und jedes Backupset sollte für den Falle des Restores in jedem Standort, über jeden Cluster zu jeder Zeit und jedem Systemstatus verfügbar sein. Im Falle eines temporären Ausfalls eines Cluster im Grid-Verbund sollten die Backupkopie automatisch nachsynchronisiert werden, sobald der betroffene Cluster wieder verfügbar ist. Eine Systemarchitektur dieser Art kann man als Backup-Cloud bezeichnen.

In der Welt der offenen Systeme wie Linux, Windows oder AIX fand diese Entwicklung der Backup-Systeme nicht im gleichen Umfang statt – bedingt durch die offene Architektur, Besonderheiten von Betriebssystemen und einer Vielzahl von Anbietern von Backup-Softwarelösungen am Markt konnte sich kein einheitlicher Backup-Cloud-Standard entwickeln. Vielmehr integrierten die einzelnen Anbieter Funktionen zur Hochverfügbarkeit in die Ebene der Software (Copy-Pool-Konzepte).

Zwar gibt es auch eine Anzahl von virtuellen Tape-Libraries für die Open-Systems Welt, allerdings bieten diese trotz Datenreplizierung – aufgrund fehlender Standards – keinen vollautomatisierten Betrieb. Das heißt im Fehlerfall sind manuelle Eingriffe am System, der Backupsoftware sowie sämtlichen Abläufen notwendig. Ein relativ neues und interessanten Konzept bietet z.B. der IBM Tivoli Storage Manager (TSM) ab Version 6.3 mit dem Feature „Node Replication“. Dabei wird durch die Backupsoftware selbst die gesamte Backup Node auf einen anderen Standort repliziert (ge-cloned). Im Fehlerfall bzw. Desaster der Rechenzentrums kann direkt die replizierte Node übernehmen und mit den vorhanden zweiten Backupsets Vorort weiter arbeiten. Ein minimaler Eingriff durch den Anwender (Aktivierung der Backup Node) ist trotzdem notwendig, da es sich hierbei auch noch nicht um ein echtes Active-Active Konzept handelt.

Zusammenfassend lässt sich festhalten, die Backup-Cloud ist heute schon Realität. Allerdings in ihrer umfassendsten Ausprägung den Mainframe-Anwendern vorbehalten. Im Bereich der offenen Welt gibt es zahlreiche Varianten und Anbieter – sowohl Backup-Hardware als auch Software – die der Anwender ausgiebig hinterfragen sollte, gerade im Bezug auf die notwendigen Aktivitäten im Falle eines Fehler bezüglich Ausfall einer Lokation. Es bleibt weiter abzuwarten, inwieweit die Hersteller von Hardware als auch Software die Idee des „Cloud Backup“ auch in der Welt der offenen Systeme voranbringen.

 

Bildquelle: Thinkstock/ iStock

©2020Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok